How can I implement abstract static methods in Java?

Question

There are numerous questions about the impossibility of including static abstract Java methods. There are also quite a lot about workarounds for this (design flaw/design strength). But I can't find any for the specific problem I'm going to state shortly.

It seems to me that the people who made Java, and quite a lot of the people who use it, don't think of static methods the way I, and many others, do - as class functions, or methods that belong to the class and not to any object. So is there some other way of implementing a class function?

Here is my example: in mathematics, a group is a set of objects that can be composed with each other using some operation * in some sensible way - for example, the positive real numbers form a group under normal multiplication (x * y = x × y), and the set of integers form a group, where the 'multiplication' operation is is addition (m * n = m + n).

A natural way to model this in Java is to define an interface (or an abstract class) for groups:

public interface GroupElement
{
  /**
  /* Composes with a new group element.
  /* @param elementToComposeWith - the new group element to compose with.
  /* @return The composition of the two elements.
   */
  public GroupElement compose(GroupElement elementToComposeWith)
}

We can implement this interface for the two examples I gave above:

public class PosReal implements GroupElement
{
  private double value;

  // getter and setter for this field

  public PosReal(double value)
  {
    setValue(value);
  }

  @Override
  public PosReal compose(PosReal multiplier)
  {
    return new PosReal(value * multiplier.getValue());
  }
}

and

public class GInteger implements GroupElement
{
  private int value;

  // getter and setter for this field

  public GInteger(double value)
  {
    setValue(value);
  }

  @Override
  public GInteger compose(GInteger addend)
  {
    return new GInteger(value + addend.getValue());
  }
}

However, there's one other important property that a group has: every group has an identity element - an element e such that x * e = x for all x in the group. For example, the identity element for positive reals under multiplication is 1, and the identity element for integers under addition is 0. In that case, it makes sense to have a method for each implementing class like the following:

public PosReal getIdentity()
{
  return new PosReal(1);
}

public GInteger getIdentity()
{
  return new GInteger(0);
}

But here we run into problems - the method getIdentity doesn't depend on any instance of the object, and should therefore be declared static (indeed, we may wish to refer to it from a static context). But if we put the getIdentity method into the interface then we can't declare it static in the interface, so it can't be static in any implementing class.

Is there any way of implementing this getIdentity method that:

1. Forces consistency over all implementations of GroupElement, so that every implementation of GroupElement is forced to include a getIdentity function.
2. Behaves statically; i.e., we can get the identity element for a given implementation of GroupElement without instantiating an object for that implementation.

Condition (1) is essentially saying 'is abstract' and condition (2) is saying 'is static', and I know that static and abstract are incompatible in Java. So are there some related concepts in the language that can be used to do this?

Answer 1

Essentially what you are asking for is the ability to enforce, at compile time, that a class defines a given static method with a specific signature.

You cannot really do this in Java, but the question is: Do you really need to?

So let's say you take your current option of implementing a static getIdentity() in each of your subclasses. Consider that you won't actually need this method until you use it and, of course, if you attempt to use it but it isn't defined, you will get a compiler error reminding you to define it.

If you define it but the signature is not "correct", and you attempt to use it differently than you have defined it, you will also already get a compiler error (about calling it with invalid parameters, or a return type issue, etc.).

Since you can't call subclassed static methods through a base type, you're always going to have to call them explicitly, e.g. GInteger.getIdentity(). And since the compiler will already complain if you try and call GInteger.getIdentity() when getIdentity() isn't defined, or if you use it incorrectly, you essentially gain compile-time checking. The only thing you're missing, of course, is the ability to enforce that the static method is defined even if you never use it in your code.

So what you have already is pretty close.

Your example is a good example that explains what you want, but I would challenge you to come up with an example where having a compile-time warning about a missing static function is a necessity; the only thing I can think of that sort of comes close is if you are creating a library for use by others and you want to ensure that you don't forget to implement a particular static function -- but proper unit testing of all your subclasses can catch that during compile-time as well (you couldn't test a getIdentity() if it wasn't present).

Note: Looking at your new question comment: If you are asking for the ability to call a static method given a Class<?>, you cannot, per se (without reflection) -- but you can still get the functionality you want, as described in Giovanni Botta's answer; you will sacrifice compile-time checks for runtime-checks but gain the ability to write generic algorithms using identity. So, it really depends on your end goal.

Answer 2

A mathematical group only has one characteristic operation, however a Java class can have any number of operations. Therefore these two concepts don't match.

I can imagine something like a Java class Group consisting of a Set of elements and a specific operation, which would be an interface by itself. Something like

public interface Operation<E> {
   public E apply(E left, E right);
}

With that, you can build your group:

public abstract class Group<E, O extends Operation<E>> {
    public abstract E getIdentityElement();
}

I know this is not entirely what you had in mind, but as I stated above, a mathematical group is a somewhat different concept than a class.

Answer 3

There may be some misunderstaning in your reasoning. You see a mathematical "Group" is as you define it (if I can remember well); but its elements are not characterized by the fact that they belong to this group. What I mean is that an integer (or real) is a standalone entity, that also belongs to Group XXX (among its other properties).

So, in the context of programming, I would separate the definition (class) of a Group form that of its members, probably using generics:

interface Group<T> {
    T getIdentity();
    T compose(T, T);
}

Even more analytic definition would be:

/** T1: left operand type, T2: right ..., R: result type */
interface BinaryOperator<T1, T2, R> {
    R operate(T1 a, T2 b);
}

/** BinaryOperator<T,T,T> is a function TxT -> T */
interface Group<T, BinaryOperator<T,T,T>> {
    void setOperator(BinaryOperator<T,T,T> op);
    BinaryOperator<T,T,T> getOperator();
    T getIdentity();
    T compose(T, T); // uses the operator
}

All that is an idea; I haven't actually touched math for a long time, so I could be wildly wrong.

Have fun!

Answer 4

There is no java way of doing this (you might be able to do something like that in Scala) and all the workarounds you will find are based on some coding convention.

The typical way in which this is done in Java is to have your interface GroupElement declare two static methods such as this:

public static <T extends GroupElement> 
  T identity(Class<T> type){ /* implementation omitted */ }

static <T extends GroupElement> 
  void registerIdentity(Class<T> type, T identity){ /* implementation omitted */ }

You can easily implement those methods by using a class to instance map or a home grown solution of choice. The point is you keep a static map of identity elements, one per each GroupElement implementation.

And here comes the need for a convention: each subclass of GroupElement will have to statically declare its own identity element, e.g.,

public class SomeGroupElement implements GroupElement{
  static{
    GroupElement.registerIdentity(SomeGroupElement.class, 
      /* create the identity here */);
  }
}

In the identity method you can throw a RuntimeException if the identity was never registered. This won't give you static checking but at least runtime checking for your GroupElement classes.

The alternative to this is a little more verbose and requires you to instantiate your GroupElement classes through a factory only, which will also take care of returning the identity element (and other similar objects/functions):

public interface GroupElementFactory<T extends GroupElement>{
  T instance();
  T identity();
}

This is a pattern typically used in enterprise applications when the factory is injected through some dependency injection framework (Guice, Spring) in the application and it might be too verbose, harder to maintain and maybe overkill for you.

EDIT: After reading some of the other answers, I agree that you should model at the group level, not the group element level, since element types could be shared between different groups. Nonetheless, the above answers provides a general pattern to enforce the behavior you describe.

EDIT 2: By "coding convention" above, I mean having a static method getIdentity in each subclass of GroupElement, as mentioned by some. This approach has the down side of not allowing generic algorithms to be written against the group. Once again, the best solution to that is the one mentioned in the first edit.

Answer 5

If you need the ability to generate an identity where the class isn't known at compile time, the first question is, how do you know, at run time, what class you want? If the class is based on some other object, then I think the cleanest way is to define a method in the superclass that means "get an identity whose class is the same as" some other object.

public GroupElement getIdentitySameClass();

That would have to be overridden in each subclass. The override would probably not use the object; the object would be used only to select the correct getIdentity to call polymorphically. Most likely, you'd also want a static getIdentity in each class (but there's no way I know of for the compiler to force one to be written), so the code in the subclass would probably look like

public static GInteger getIdentity() { ... whatever }

@Override
public GInteger getIdentitySameClass() { return getIdentity(); }

On the other hand, if the class you need comes from a Class<T> object, I think you'll need to use reflection starting with getMethod. Or see Giovanni's answer, which I think is better.

Answer 6

We all agree, if you want to implement groups you are going to need a group interface and classes.

public interface Group<MyGroupElement extends GroupElement>{
    public MyGroupElement getIdentity()
}

We implement the groups as singletons so we can access getIdentity statically through instance.

public class GIntegerGroup implements Group<GInteger>{

    // singleton stuff
    public final static instance = new GIntgerGroup();
    private GIntgerGroup(){};

    public GInteger getIdentity(){
        return new GInteger(0);
    }
}

public class PosRealGroup implements Group<PosReal>{

    // singleton stuff
    public final static instance = new PosRealGroup();
    private PosRealGroup(){}        

    public PosReal getIdentity(){
        return new PosReal(1);
    }
}

if we also need to be able to get the identity from a group element, I would update your GroupElement interface with:

public Group<GroupElement> getGroup();

and GInteger with:

public GIntegerGroup getGroup(){
    return GIntegerGroup.getInstance(); 
}

and PosReal with:

public PosRealGroup getGroup(){
    return PosRealGroup.getInstance(); 
}

Answer 7

" the method getIdentity doesn't dependonany instance of the object, and should therefore be declared static"

Actually, if it does not depend on any instance, it can just return some constant value, it does not have to be static.

Just because a static method does not depend on an instance, it does not mean you should use it always for this kind of situation.