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.] 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
