Question

Is there a semantic difference between these two declaration or is it only syntactic sugar?

class C<T extends C> vs class C<T extends C<T>>

Background: I recently answered a question on generics using the C<T extends C> approach and a peer provided a similar answer based on C<T extends C<T>>. At the end, both alternatives provided the same result (in the context of the question asked). I remained curious about the difference between these two constructs.

Is there’s a semantic difference? If so, what are the implications and consequences of each approach?

Answer 1

Sure – often these “self types” are used to constrain subtypes to return exactly their own type. Consider something like the following:

public interface Operation {
    // This bit isn't very relevant
    int operate(int a, int b);
}

public abstract class AbstractOperation<T extends AbstractOperation<T>> {
    // Lets assume we might need to copy operations for some reason
    public T copy() {
        // Some clever logic that you don't want to copy and paste everywhere
    }
}

Cool – we have a parent class with a useful operator which can be specific to subclasses. For instance, if we create an AddOperation, what can its generic parameters be? Because of the “recursive” generic definition, this can only be AddOperation giving us:

public class AddOperation extends AbstractOperation<AddOperation> {
    // Methods etc.
}

And hence the copy() method is guaranteed to return an AddOperation. Now lets imagine we’re silly, or malicious, or creative, or whatever, and try to define this class:

public class SubtractOperation extends AbstractOperation<AddOperation> {
    // Methods etc.

    // Because of the generic parameters, copy() will return an AddOperation
}

This will be rejected by the compiler because the generic type isn’t within its bounds. This is quite important – it means that in the parent class, even though we don’t know what the concrete type is (and it might even be a class that didn’t exist at compile time), the copy() method will return an instance of that same subclass.

If you simply went with C<T extends C>, then this weird definition of SubtractOperation would be legal, and you lose the guarantees about what T is in that case – hence the subtract operation can copy itself into an add operation.

This isn’t so much about protecting your class hierarchy from malicious subclasses, it’s more that it gives the compiler stronger guarantees about the types involved. If you’re calling copy from another class altogther on an arbitrary Operation, one of your formations guarantees that the result will be of the same class, while the other will require casting (and might not be a correct cast, as with the SubtractOperation above).

Something like this for example:

// This prelude is just to show that you don't even need to know the specific
// subclass for the type-safety argument to be relevant
Set<? extends AbstractOperation> operations = ...;
for (AbstractOperation<?> op : operations) {
    duplicate(op);
}

private <T extends AbstractOperation<T>> Collection<T> duplicate(T operation) {
    T opCopy = operation.copy();
    Collection<T> coll = new HashSet<T>();
    coll.add(operation);
    coll.add(opCopy);

    // Yeah OK, it's ignored after this, but the point was about type-safety! :)
    return coll; 
}

The assignment on the first line of duplicate to T wouldn’t be type-safe with the weaker of the two bounds you proposed, so the code wouldn’t compile. Even if you define all of the subclasses sensibly.