Hi, Gary Gregory <garydgreg...@gmail.com> schrieb am Mo., 6. Juni 2016 um 22:30 Uhr:
> On Mon, Jun 6, 2016 at 11:44 AM, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > > > On Jun 6, 2016, at 11:38 AM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > > On Mon, Jun 6, 2016 at 11:11 AM, Jochen Wiedmann < > > jochen.wiedm...@gmail.com <mailto:jochen.wiedm...@gmail.com>> > > > wrote: > > > > > >> ---------- Forwarded message ---------- > > >> From: Ralph Goers <ralph.go...@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.] > Yes, this discussion started with "let's write something down". I haven't seen any objections to my initial proposal so I'm going to document that on our website soon. Benedikt > > 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: garydgreg...@gmail.com | ggreg...@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 >
