Use-cases for version ranges?
alex.buckley at oracle.com
Mon Nov 21 14:09:16 PST 2011
On 11/21/2011 1:55 PM, Eric Johnson wrote:
> Also, I'd like to point out distinctions between changing the name of a
> new version of the interface, vs. use of multiply inherited abstract
> classes (which is essentially this proposal). The proposal doesn't
> address that:
> * Multiply inherited interfaces with defaults then result in
> possible name collisions, when a client implements both
> "interfaces" and both have defaults with the same name but
> different implementations.
Yes, this is a problem at runtime under inconsistent separate
compilation. Brian Goetz has been discussing it over in lambda-land.
> * Just as with abstract classes now, if you *add* a method, it is
> always possible that a subclass already has a method of that name.
And so while the subclass overrides the interface method (assuming the
name, signature, and return type are all satisfactory), we're back to
the question of behavorial compatibility: does the subclass's method
provide a useful override of the method newly added in a supertype? I
agree the lambda-inspired mechanisms could use some help from the module
> So, I'm still stuck at the question: what's compatibility, then? At
> least with the current model, if you change the name of the interface,
> every downstream implementation must make an explicit decision to
> embrace the new API.
No disagreement here.
More information about the jigsaw-dev