Use-cases for version ranges?

[cowwoc]

     Sorry Alex. You really hit a nerve with these slides.

     It's amazing how far people will go to stuff lambda expressions 
down our throats. So now you're killing interfaces and adding multiple 
inheritance to Java? Great.... just great. Instead of killing 
interfaces, how about allowing developers to replace an interface with 
an abstract Class without breaking compatibility? That's essentially 
what you're doing anyway... Also, shouldn't "spliterable" be called 
"splitable"?

     This is precisely what is wrong with the way the Java APIs are 
being evolved. Instead of breaking compatibility on a *class* level 
you're breaking compatibility on a *language* level and acting as if 
nothing is wrong. Needless to say, I am upset. If you were to fork Java 
into version 2.x and break the necessary classes at the same time the 
change might actually be less profound than introducing multiple 
inheritance. You could rewrite class files from version 1.x to 2.x as 
needed, similar to Retroweaver.

     To answer your original question, being able to evolve interfaces 
without breaking backwards compatibility helps but it doesn't really 
change my view of semantic compatibility. I remember plenty of Swing 
bugs I reported which were closed as WON'T FIX because doing so would 
have broken backwards compatibility for existing users. I'm talking 
about cases where someone made a mistake in the design and it could not 
be fixed for the rest of time. At the end of the day there needs to be a 
way for us to make changes that break compatibility in a reasonable 
manner. Had Sun/Oracle taken this route, they could have slowly replaced 
deprecated classes and methods over time. Even Microsoft dropped Windows 
95 after 10 years.

Gili

On 21/11/2011 2:52 PM, Alex Buckley [via jigsaw-dev] 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
> 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
>
>
> ------------------------------------------------------------------------
> If you reply to this email, your message will be added to the 
> discussion below:
> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011483.html 
>
> To unsubscribe from Use-cases for version ranges?, click here 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5002801&code=Y293d29jQGJicy5kYXJrdGVjaC5vcmd8NTAwMjgwMXwxNTc0MzIxMjQ3>.
> NAML 
> <http://jigsaw-dev.1059479.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.InstantMailNamespace&breadcrumbs=instant+emails%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> 
>



--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5011709.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.