Problem of defender methods with generic methods

[Steven Simpson]

On 15/11/10 22:50, Alex Buckley wrote:
> You and Steven have identified a valuable idiom that avoids new subtypes 
> - we can call it "conditional inheritance" if you like - but 
> unfortunately the generics mechanism cannot express it. Namely, the 
> bound of a type variable can be _either_ another type variable _or_ a 
> combination of classes and interfaces. (See JLS3 4.4.)
>
> The trouble is erasure: if a type variable's bound could be 'T & 
> Comparable<...>', then it would not be clear whether to erase max's 
> return type to Object (the erasure of T) or Comparable (the erasure of 
> Comparable<...>). I guess we could pick the former, but the Signature 
> attribute would want to record both T and Comparable<..> for later 
> typechecking of A's witness from the call site. (Does it subtype List's 
> type argument _and_ Comparable<..> ?)

Could it be done like this?:

interface List<T> {
  ...

  <new T extends Comparable<? super T>> extension T max() default Collections.max;
}

The generic method signature as it appears in the bytecode would be
almost the same, but with some extra flag on T, e.g. '!':

<!T::Ljava/lang/Comparable<-TT;>;>()TT

...indicating that it's a refinement of the containing class's generic
signature, not a completely separate T.  These would both be available
to the compiler to statically check each call.