Use-cases for version ranges?
eric at tibco.com
Mon Nov 21 13:55:23 PST 2011
On 11/21/11 8:49 PM, Alex Buckley wrote:
> Hi Gili and Eric,
> Java SE 8 is extremely likely to support the addition of methods to
> interfaces in a manner which is binary-compatible _and_
> source-compatible. See slide 52 onwards in
Thanks for pointing at those slides.
> How does this affect your view of semantic compatibility and version
It might help. Lots of reasons to be potentially concerned about it,
though. It looks like it is really just a different way of making
abstract classes, but where you can still multiply inherit. Since this
email thread isn't about all the features of Java 8, I'll just leave the
commentary on that notion aside.
The key point I was making, though, is still there. Compatibility must
be defined, at least if you're going to chase the notion of version
ranges supporting backward compatibility. All this proposal does is give
me a new way to solve one portion of the compatibility question without
resorting to awkward class names.
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
* 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.
* 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.
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.
> On 11/21/2011 11:41 AM, cowwoc wrote:
>> Hi Eric,
>> On 21/11/2011 5:43 AM, Eric Johnson [via jigsaw-dev] wrote:
>>> Trouble is, the Java community doesn't seem to like the idea of a new
>>> named interface with the additional of even one method to an interface.
>>> But is that perhaps just because the JDK has acculturated people to the
>>> idea that they don't need to do that? It seems to me that any version
>>> scheme that attempts to cover up this problem will likely just add to
>>> the confusion, rather than resolve the problem. We either have to stick
>>> a stake in the ground and declare what we mean by backward compatible,
>>> or admit that there isn't a single notion, and therefore version ranges
>>> just mean what people want them to mean.
>> My problem with this approach is java.util.Collections followed by
>> Collections2 in Guava. Another example, Futures vs MoreFutures in Guava.
>> These are examples of class subclassing, not interface extension, but
>> the problem is the same: once you pick a good name it's extremely
>> difficult to come up with yet another good name for the same thing. How
>> many times do you think you could extend an interface before you run out
>> of names? Twice? Three times maybe?
>> I'm also tired of Java features having their designs crippled in
>> the name of backwards-compatibility. I'm personally in favor of each
>> author declaring a backwards compatibility policy and breaking
>> compatibility as necessary. In the case of the JDK, you can imagine
>> removing deprecated methods after 5 years. Projects like Guava give you
>> 6 months. The point is that you can't keep backwards compatibility
>> forever, especially in light of the requirement you mentioned that
>> developers may not add any new methods ;)
More information about the jigsaw-dev