On Mon, 1 May 2017 09:08:23 +1000, Peter Ansell wrote:
Jenkins now requires Java-8 as its base runtime environment on the regular release channel, with its LTS channel moving to Java-8 in a few weeks:https://jenkins.io/blog/2017/04/10/jenkins-has-upgraded-to-java-8/
Thanks for the notice. As Sebb aptly reminded, this is however independent of why we might want a component to upgrade its Java version, but ...
That one bit me, as there is a bug updating on older Ubuntu versions that don't carry a Java-8 JDK in their standard repositories so you need to pull in the webupd8 PPA or the openjdk PPA: https://issues.jenkins-ci.org/browse/JENKINS-43629 The statistics that backed the Jenkins decision were interesting, but not necessarily relevant to other production applications: https://jenkins.io/blog/2017/01/17/Jenkins-is-upgrading-to-Java-8/
... this link is yet another rephrase of why a community-driven project might want to keep up with its environment: "Being also a developer community, we want Jenkins to be appealing to contributors." Regards, Gilles
Cheers, Peter On 1 May 2017 at 02:22, Matt Sicker <[email protected]> wrote:Supporting Java 6 is going to continue to become harder and harder to do with infrastructural upgrades across the board. Recent versions of Gradle require Java 7 to run, for example, just like Jenkins, even though you can still use those to compile for Java 6. Ant has finally moved on from the Java 5 baseline, though IIRC, they jumped straight to Java 8. Considering how long it was between Maven 3.3.9 and 3.5.0, I'm guessing the discussionthere about the baseline Java version is still ongoing.Really, what this is all pointing toward is that the greater Java developer community is moving on from Java 6, and if we want to continue supporting Java 6 in projects that otherwise shouldn't need anything newer, we may need some better tooling or documented standards on how to continue doing so. If Java 6 just never dies, then I almost think that we'll need to takea leaf from the Javascript developer community and get some sort oftranspiler to support Java 6 using newer syntax and libraries (which couldbe compile-time re-linked to compatibility libraries).On 30 April 2017 at 09:55, Gilles <[email protected]> wrote:On Sun, 30 Apr 2017 15:39:20 +0100, sebb wrote:On 30 April 2017 at 15:32, Gilles <[email protected]> wrote:On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote:On 29 April 2017 at 19:10, Gilles <[email protected]> wrote:Hi. On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote:Please note I wrote an issue concerning this last week or so. https://issues.apache.org/jira/browse/NUMBERS-21I noticed when moving code from [math] to [numbers] that [math]targets 7.As a general rule, this must formally asked on the "dev" ML. [And, we'll take for granted that if no one raises an objection within 72 hours, the proposal is accepted.] I had to make some minor downgrades in the code (use of diamondoperator).Given that [math] targets Java 7 and [numbers] is based on it, I seeno reason [numbers] shouldn't target 7 as well.That's fine with me; however let's note (for the record) that the last official release of CM (3.6.1) was still Java 5 (five) compatible. I don't think (TBC) that any of the CM codes intended (as of now) forinclusion _requires_ Java 7.Hence my question about the necessity (seems not) or willingness (could well be, if just for the comfort of contributors) to upgrade.Now, concretely, you could make the "downgrades" and the code isnow Java 6 compatible. However, as concretely, it is not obvious that we want to loose more time fiddling with Jenkins to make it perform the build of code targeted to old Java.IMO it is wrong for Jenkins to dictate the Java compat level of theitems it builds.I agree. Besides, it is not difficult to do.Then why doesn't INFRA do it when they perform an upgrade that breaks what used to work?Don't ask me, ask them...I first asked here because I might have missed an announcement explaining how to upgrade the config. [I seem to recall having done what was required when the issue with Java 6 was first mentioned; then it broke again.]Help welcome, since I must have missed the "easy" part in myattempts to fix it...Which job is failing?I've just seen that you fixed it for "RNG". Thanks! I've reviewed the changes and did the same in "Numbers". Fixed now! Thanks, GillesGillesRegards, GillesOn Fri, Apr 28, 2017 at 6:30 PM, sebb <[email protected]> wrote:On 28 April 2017 at 16:05, Matt Sicker <[email protected]> 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 todo using the -Pjava-1.6 profile. > On 28 April 2017 at 09:51, sebb <[email protected]> wrote: >>> On 28 April 2017 at 13:01, Gilles <[email protected]>>> wrote: >> > Hi. >> > >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote: >> >> >> >> On Apr 27, 2017 8:21 AM, "Gilles" < [email protected]> 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 APIsyou want >> to >> >>> use for it more so than what's current. >> >>> >> >>>> >> Indeed, the question could be rephrased as: Is there anythingto 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 orupgrading >> 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 gothrough >> > 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 Java7. >> >> 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 mightbe>> 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 < [email protected]> 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 tocomplicate >> >>>> >> >>>> the Jenkins configuration: >> >>>> https://builds.apache.org/vie w/Apache%20Commons/job/Commons_ >> >>>> Numbers/14/console >> >>>> >> >>>> For a new component, shouldn't we just go to Java 8? >> >>>> >> >>>> >> >>>> Gilles >> >>>> >> > >> >--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]-- Matt Sicker <[email protected]>--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
