commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [ALL] About binary compatibility
Date Mon, 06 Jun 2016 20:30:34 GMT
On Mon, Jun 6, 2016 at 11:44 AM, Ralph Goers <ralph.goers@dslextreme.com>
wrote:

>
> > On Jun 6, 2016, at 11:38 AM, Gary Gregory <garydgregory@gmail.com>
> wrote:
> >
> > On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann <
> jochen.wiedmann@gmail.com <mailto:jochen.wiedmann@gmail.com>>
> > wrote:
> >
> >> ---------- Forwarded message ----------
> >> From: Ralph Goers <ralph.goers@dslextreme.com>
> >> Date: Mon, Jun 6, 2016 at 1:11 AM
> >> Subject: Re: [ALL] About binary compatibility
> >> To: Commons Developers List <dev@commons.apache.org>
> >>
> >>
> >> I think we should adopt Java 9’s multi-release jars [1] as standard
> >> practice.  While this won’t let us update our APIs without breaking
> >> compatibility (which may still be necessary), it will allow us to
> >> leverage some features in newer versions of Java without worrying
> >> about breaking backward compatibility.
> >>
> >> Strong disagreement. Java 9 is not even out, and I heard noone express
> >> any desire to *use* these beasts. In other words: We'd serve a
> >> non-existing demand. That can't help anyone,
> >> in particular not ourselves.
> >>
> >
> > Yeah, it seems a little early to jump on that bandwagon.
> >
> > I'd rather keep a mainline of development of new releases on a recent JRE
> > like Java 7 or 8 and let people who really want older JREs maintain
> > branches.
> >
>
> Gary, your response seems at odds with what I am saying. I’m not talking
> about supporting Java 6.  What I am suggesting is that this feature in Java
> 9 will let you take advantage of features in Java 8 or 9 while still being
> able to have the same jar run in Java 7.  In other words your can have a
> project where the Maven is told the target runtime is Java 7 but can take
> advantage of features in Java 8 or 9.  You don’t have to delay taking
> advantage of features just because you aren’t ready to abandon your Java 7
> (or 8 when that is relevant) users.
>

Howdy,

[These chats are fun, but we usually end up deciding nothing and delegating
Java platform decisions to individual components, so maybe we should make
_that_ a more visible Commons guideline if it is not already.]

I think what I am really saying (and not expressing it clearly!) is that I
am not looking forward to debugging these scenarios; I'd rather keep it
simple and say: we require Java X for release Y. Once a component jumps on
Java 7, I want to make it Java 7 all over (try-with-resources, diamond
notation, and so on.)

The argument I hear/read over and over is: Folks that are stuck on
maintaining a Java 6 (for example) stack are not going to want to change
anything in 3rd party dependencies beyond getting a security
or critical bug fix. So for me, if we release a new version of a component,
it can do whatever the "do-ers" want it to do. If someone says, "Hey! This
won't work on Java 6", I say "It will once you put in the work to backport
whatever you want in a branch!" ;-) Same argument for moving to Java 8. At
work, we are still stuck on Java 7, but I am not going to stop any Commons
component from going to Java 8, even though that would not be useful for me
today (at work.)

I hope that helps ;-)
Gary


>
> Ralph
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message