If it's compiled at a higher target version, it's not a drop-in replacement. They must upgrade their JRE. One might argue that's actually *less* backward compatible. We've had this debate before. I don't really care which way we go, but let's make sure we stay true to the philosophy (if we want to maintain that philosophy).
On Tue, Jun 14, 2016 at 10:57 AM Gary Gregory <garydgreg...@gmail.com> wrote: > On Jun 14, 2016 7:51 AM, "James Carman" <ja...@carmanconsulting.com> > wrote: > > > > The trick is if we want to require a major version upgrade to bump JDK > > levels. That's why you'd want to bump it now if possible. > > We've not required major version bumps for Java bumps in the past. > > Gary > > > > > On Tue, Jun 14, 2016 at 10:41 AM Matt Sicker <boa...@gmail.com> wrote: > > > > > I'd prefer to get to 1.7 as soon as possible, but if the API is ready > for a > > > 1.0 release already, we could wait for 1.1 or 1.2 before going full > 1.7. > > > > > > On 14 June 2016 at 06:16, Stian Soiland-Reyes <st...@apache.org> > wrote: > > > > > > > +1 to JDK7 on crypto > > > > On 14 Jun 2016 10:25 a.m., "Sun, Dapeng" <dapeng....@intel.com> > wrote: > > > > > > > > > > Then next release(after 1.0.0) must be a major release you mean? > > > > > > If there are no potential users looking for JDK 1.6, dropping now > > > > should > > > > > be good idea IMO. > > > > > > > > > > Thank Uma, I just checked there is no much changes on upgrading JDK > to > > > > > 1.7, I think we can upgrade before this release. > > > > > > > > > > Is there anyone have other opinions? > > > > > > > > > > Regards > > > > > Dapeng > > > > > > > > > > -----Original Message----- > > > > > From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com] > > > > > Sent: Tuesday, June 14, 2016 4:21 PM > > > > > To: Commons Developers List > > > > > Subject: Re: [crypto] On Java 6, really? > > > > > > > > > > Then next release(after 1.0.0) must be a major release you mean? > > > > > If there are no potential users looking for JDK 1.6, dropping now > > > should > > > > > be good idea IMO. > > > > > > > > > > I also remembered that we wanted to mark 1.0.0 release as Alpha > right? > > > > > (just a question) > > > > > > > > > > Regards, > > > > > Uma > > > > > > > > > > On 6/14/16, 12:27 AM, "Sun, Dapeng" <dapeng....@intel.com> wrote: > > > > > > > > > > >Thank Gary, Benedikt, Marcelo, sebb, James, Jochen, ecki, Ralph > and > > > > > >Matt for all your input. > > > > > > > > > > > >How about make a conservative decision: regarding the first > > > > > >release(1.0.0), we keep the JDK version as 1.6, and we wouldn't > > > support > > > > > >JDK 1.6 for the releases after 1.0.0. > > > > > > > > > > > >Regards > > > > > >Dapeng > > > > > > > > > > > >-----Original Message----- > > > > > >From: Matt Sicker [mailto:boa...@gmail.com] > > > > > >Sent: Wednesday, June 08, 2016 6:18 AM > > > > > >To: Commons Developers List > > > > > >Subject: Re: [crypto] On Java 6, really? > > > > > > > > > > > >I'd imagine that close to 100% of users who are on Java 6 are not > > > > > >upgrading anything else, either, nor would they be adding in new > > > > > >dependencies. Every Java 6 project I've come across lately has > been in > > > > > >legacy maintenance mode (just like Java 6 itself). > > > > > > > > > > > >On 7 June 2016 at 16:47, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > > > > > > > > >> Let's not forget that customers are paying Oracle to get Java 6 > > > > updates. > > > > > >> > > > > > >> Gary > > > > > >> On Jun 7, 2016 1:24 PM, "Ralph Goers" < > ralph.go...@dslextreme.com > > > > > > > >>wrote: > > > > > >> > > > > > >> > I really don¹t think the premier & extended support dates > should > > > > > >> > really mean much, except as an indicator of how many users of > that > > > > > >> > version might still exist. Basically, no new features are > going > > > to > > > > > >> > be added to Java > > > > > >> so I > > > > > >> > don¹t think we should be targeting new features there either. > If > > > > > >> > there > > > > > >> is a > > > > > >> > bug that needs to be fixed it should be possible to do it on a > > > > > >> > branch of the the release for that version of Java. The web > site > > > > > >> > should clearly indicate which versions of the component > support > > > the > > > > > >> > appropriate Java versions. > > > > > >> > > > > > > >> > Ralph > > > > > >> > > > > > > >> > > On Jun 7, 2016, at 12:26 PM, sebb <seb...@gmail.com> wrote: > > > > > >> > > > > > > > >> > > I have just checked Oracle support for Java 6. > > > > > >> > > > > > > > >> > > The Support Life for Java 6 has been extended to Dec 2018 > [1] I > > > > > >> > > think this means that there are critical systems that cannot > yet > > > > > >> > > be updated to Java 7+. > > > > > >> > > > > > > > >> > > This does not mean that we should ensure that all Commons > code > > > > > >> > > still works on Java 6. > > > > > >> > > But it should be taken into account when evaluating the pros > and > > > > > >> > > cons of requiring a later version. > > > > > >> > > > > > > > >> > > [1] > > > > > >> > > > > > http://www.oracle.com/technetwork/java/eol-135779.html#extended6 > > > > > >> > > > > > > > >> > > On 7 June 2016 at 20:02, Jochen Wiedmann > > > > > >> > > <jochen.wiedm...@gmail.com> > > > > > >> > wrote: > > > > > >> > >>> Gary Gregory <garydgreg...@gmail.com> wrote on Tue., 7. > Juni > > > > > >> > >>> 2016 > > > > > >> > >>> > > > > > >> > >>>> Are we really starting a new component on a dead platform > > > like > > > > > >> > >>>> Java > > > > > >> 6? > > > > > >> > >> > > > > > >> > >> > > > > > >> > >> You are, of course, right, that the component is more than > > > > > >> > >> welcome to use another version. OTOH, given our latest > > > > > >> > >> experiences: Is this really someting, that we should care > for? > > > > > >> > >> IMO, let the component have, whatever they want. > > > > > >> > >> > > > > > >> > >> Jochen > > > > > >> > >> > > > > > >> > >> > > > ---------------------------------------------------------------- > > > > > >> > >> - > > > > > >> > >> ---- To unsubscribe, e-mail: > > > dev-unsubscr...@commons.apache.org > > > > > >> > >> For additional commands, e-mail: > dev-h...@commons.apache.org > > > > > >> > >> > > > > > >> > > > > > > > >> > > > > > ----------------------------------------------------------------- > > > > > >> > > - > > > > > >> > > --- To unsubscribe, e-mail: > dev-unsubscr...@commons.apache.org > > > > > >> > > For additional commands, e-mail: > dev-h...@commons.apache.org > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > ------------------------------------------------------------------- > > > > > >> > - > > > > > >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > >> > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > >> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > >Matt Sicker <boa...@gmail.com> > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Matt Sicker <boa...@gmail.com> > > > >
