Use-cases for version ranges?

[Alex Buckley]

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 
http://blogs.oracle.com/abuckley/resource/QConSF2011-JavaSE78.pdf.

How does this affect your view of semantic compatibility and version ranges?

Alex

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 ;)
>
> Gili