On Apr 29, 2017 6:47 AM, "Raymond DeCampo" <r...@decampo.org> wrote:
Please note I wrote an issue concerning this last week or so. https://issues.apache.org/jira/browse/NUMBERS-21 I noticed when moving code from [math] to [numbers] that [math] targets 7. I had to make some minor downgrades in the code (use of diamond operator). Given that [math] targets Java 7 and [numbers] is based on it, I see no reason [numbers] shouldn't target 7 as well. Sounds fine with me. Gary On Fri, Apr 28, 2017 at 6:30 PM, sebb <seb...@gmail.com> wrote: > On 28 April 2017 at 16:05, Matt Sicker <boa...@gmail.com> wrote: > > If you're going to build for Java 6 using Java 7, then you should really > > use something like < > > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to > > prevent accidental usage of Java 7. > > And/Or actually use Java 6 to compile/test, which is pretty easy to do > using the -Pjava-1.6 profile. > > > On 28 April 2017 at 09:51, sebb <seb...@gmail.com> wrote: > > > >> On 28 April 2017 at 13:01, Gilles <gil...@harfang.homelinux.org> wrote: > >> > Hi. > >> > > >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote: > >> >> > >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gil...@harfang.homelinux.org> > wrote: > >> >> > >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote: > >> >> > >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you > want > >> to > >> >>> use for it more so than what's current. > >> >>> > >> >> > >> >> Indeed, the question could be rephrased as: Is there anything to > loose > >> >> (for a new component) if we allow the larger API of Java 8? > >> >> > >> >> > >> >> I hear people are still using Java > >> >>> > >> >>> 6, but I doubt those projects are adapting new libraries or > upgrading > >> any > >> >>> of their dependencies as it is... > >> >>> > >> >> > >> >> That has seemed logical to me for a long time... > >> >> > >> >> > >> >> +1 > >> >> > >> >> I say pick the version you think is best. > >> > > >> > > >> > At this point, I can't say exactly. > >> > The current code doesn't seem to need Java APIs beyond 6, but other > >> > utilities yet to be added might benefit. > >> > The only argument for leaving Java 6 is that we have to go through > >> > hoops with the Jenkins configuration. > >> > >> That is not an argument for upping the Java version > >> > >> > Currently it fails in a way that looks cryptic to me. > >> > >> That's because Jenkins now requires Java 7 to run Maven jobs, though > >> it does not seem to need it for all job types. > >> > >> > So, unless someone can fix it, I'll bump the dependency to Java 7. > >> > >> Huh? > >> Surely you can just tell Jenkins to use Java 7 to build and test? > >> There's no need for the source to be updated as well (there might be > >> some Javadoc warnings, I suppose, but those can be fixed without > >> compromising Java 6 compat.) > >> > >> But it's pretty easy to fix so it builds and tests using Java 6 - > >> which job is it? > >> > >> > Regards, > >> > Gilles > >> > > >> > > >> > > >> >> > >> >> Gary > >> >> > >> >> > >> >> Regards, > >> >> Gilles > >> >> > >> >> > >> >> On 27 April 2017 at 09:41, Gilles <gil...@harfang.homelinux.org> > wrote: > >> >>> > >> >>> > >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote: > >> >>>> > >> >>>> > >> >>>> Hi. > >> >>>>> > >> >>>>> > >> >>>>> The POM indicates: > >> >>>>> > >> >>>>> <maven.compiler.source>1.6</maven.compiler.source> > >> >>>>> <maven.compiler.target>1.6</maven.compiler.target> > >> >>>>> > >> >>>>> but also: > >> >>>>> > >> >>>>> <commons.release.desc>(requires Java > 7+)</commons.release.desc> > >> >>>>> > >> >>>>> Which is wrong? > >> >>>>> > >> >>>>> > >> >>>>> Also, please not that keeping 1.6 compatibility seems to > complicate > >> >>>> > >> >>>> the Jenkins configuration: > >> >>>> https://builds.apache.org/view/Apache%20Commons/job/Commons_ > >> >>>> Numbers/14/console > >> >>>> > >> >>>> For a new component, shouldn't we just go to Java 8? > >> >>>> > >> >>>> > >> >>>> Gilles > >> >>>> > >> > > >> > > >> > --------------------------------------------------------------------- > >> > 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 > >
