Updated State of the Lambda

Gernot Neppert mcnepp02 at googlemail.com
Tue Dec 13 01:25:13 PST 2011


2011/12/12 Brian Goetz <brian.goetz at oracle.com>:
> Yes, this is covered.  The formal model handles this case in the rule
> T-ClassFromDefault (Figure 6), through the precondition mtype(C)=mtype(J);
> this means that it is a type error if a class tries to inherit a default
> where the classes' notion of the return type differs from the
> implementation's return type.

Thanks for pointing me to the relevant section. So this has been thought of!

But:

>
> While technically one could read this and not require a compilation error at
> the point where an interface covariantly overrides a default method without
> either providing a new default clause (concrete or default none), it would
> be silly to push the error to the point where that interface is inherited by
> a class.  So the error happens at the point at which the pollution is
> introduced.
>

Does this mean that an extended interface BidirectionalMap<K,V>
extends java.util.Map<K,V> {
   Set<V> values();
}

will be rendered incompilable, should the JDK developers decide to add
a default body to interface java.util.Map {
   Collection<V> values() default {...}
}

? Wouldn't this be an annoying incompatibility?
By simply leaving the re-abstraction-by-re-declaration rules intact,
no such incompatibilities would be introduced.


More information about the lambda-dev mailing list