Proposal : Jenkins to require Java 8

[nicolas de loof]

Changed the thread topic, as it sounds it's not appealing enough to get feedback :)

2014-09-23 18:33 GMT+02:00 nicolas de loof <nicolas...@gmail.com>:

Hi folks,

we had discussions here about requiring java 6 for Jenkins. I don't see a major benefit for using it, as new API/feature would offer border-line changes to jenkins codebase. Same for Java 7 (which is announced EOL anyway)

Makes me wonder if we could start discussion on migrating to Java 8. This would allow use of default methods for interface based extension, lambdas, and few other significant features for plugin and core developers. This won't prevent people to build project on java 1.1 if they wish.

wdyt ?

[domi]

I fully agree with Nicolas. And maybe we could use this chance to jump to v2 of Jenkins and even think about changing/removing/refactor some stuff we currently do with ugly workarounds. I’m sure there are a couple of things core developers would love to have fixed...

And plugins should?/could? then really express there compatibility with the new version. 

regards Domi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Kutter]

Hi Nicolas & all,

>> Makes me wonder if we could start discussion on migrating to Java 8.
This
>> would allow use of default methods for interface based extension,
>> lambdas,
>> and few other significant features for plugin and core developers. This
>> won't prevent people to build project on java 1.1 if they wish.

Just want to throw in that java 8 is not yet available on all platforms
(like AIX, HP-UX and probably some other less frequently used commercial
UNIXes).
Requiring java 8 won't prevent people from building with older versions,
but it will (probably) prevent running a build node on one of these
platforms.

Martin

[nicolas de loof]

Lack of a recent JDK on some exotic systems (*) was already a blocker for Java 6 upgrade, that's a real issue, but on the other side we can't stuck to java 5 just because SCO-Unix don't have a better JDK. 

As suggested by Dominik, I think starting a 2.x branch to require java 8 would make sense. Springframework major releases were driven by minimal JDK updates, for the same reason, as this is the main compatibility breaker form a user point of view.

(*)  I wonder anyone tried to build OpenJDK on those platforms, even not officially supported

[teilo]

Hmm - even my raspberry pi has jdk 8 support[1]

Doesn't the openJDK support AIX now[2]? (not that I would run my jenkins cluster on openJDK[3] - but it does provide hope for those that need it)

This would just leave HP-UX out in the cold.

/James

[1] http://www.oracle.com/technetwork/java/javase/downloads/jdk8-arm-downloads-2187472.html
[2] http://cr.openjdk.java.net/~simonis/ppc-aix-port/
[3] been bitten by OpenJDK 7s buggyness and it has taineted be - even though 8 is far supperior in quatlity

[Daniel Beck]

On 24.09.2014, at 11:48, Martin Kutter <martin...@fen-net.de> wrote:

> Just want to throw in that java 8 is not yet available on all platforms
> (like AIX, HP-UX and probably some other less frequently used commercial
> UNIXes).

I checked the anonymous usage stats a few weeks ago:
Out of 93,400 installs, we know the master's OS for 85,200 of them.
285 are AIX. 120 are HP-UX. 50 installs total on OpenBSD, Darwin, OS/400, z/OS and NetBSD.

Not relevant enough IMO if the advantages are significant.

I can provide the queries I used if anyone wants to verify these.

[oliver gondža]

On Wed, 24 Sep 2014 19:42:27 +0200, Daniel Beck <m...@beckweb.net> wrote:

> I checked the anonymous usage stats a few weeks ago:
> Out of 93,400 installs, we know the master's OS for 85,200 of them.
> 285 are AIX. 120 are HP-UX. 50 installs total on OpenBSD, Darwin,
> OS/400, z/OS and NetBSD.
>
> Not relevant enough IMO if the advantages are significant.

Do we have stats for connected slaves? I expect there is significantly
more instances that are using exotic platforms to power some of their
slaves but not master.

--
oliver

[Daniel Beck]

On 24.09.2014, at 19:53, oliver gondža <ogo...@gmail.com> wrote:

> Do we have stats for connected slaves? I expect there is significantly more instances that are using exotic platforms to power some of their slaves but not master.

Since only relatively few Jenkins installs actually seem to use slaves, that's not the case.

Out of ~27300 slaves, only ~200 are known to run any of the platforms mentioned above. Unfortunately, we don't know the OS of ~6500 slaves and I don't see why this should be the case.

(Of course, one could argue that the more likely an organization is to have lots of nodes and use obscure commercial Unixes, the less likely it is they participate in anonymous usage statistics -- but that makes it their problem IMO.)

[Kohsuke Kawaguchi]

I think we need to ask this to the users list and what people say. I'm happy to pose this question in JUC Bay Area to get the feel, too.

As much as I love the idea as a developer, this does have a significant negative impact on the users.

For one, we aren't just talking about optionally taking advantages of Java8 library features, like we do today for Java7. Here you are proposing to compile version 52 class files that only Java8 understands.

It is also not just so called esoteric OSes that do not have Java8. Take Ubuntu for example. The current latest release 14.04 still doesn't have Java8 as a native package. IIUC you currently have to rely on installing it from somebody's private repository (and I have no way of trusting these guys.) This means our DEB package will not be installable on its own. 

Here's another one. IBM still hasn't released JDK8. If you are an IBM shop and need to use IBM JDK for support contracts, you'll be left behind.

I'd be happy to be proven wrong, but I don't think JDK8 dependency will be happening any time soon.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Kohsuke Kawaguchi

[Baptiste Mathus]

I'm absolutely +1 on the advantages on the programming model that defining a JDK8 as a minimum JDK would give us. And like Nicolas, I also think JDK7 is not really worth it as 8 is.

And Jenkins is one of those tools that has somehow a lower barrier on that requirement upgrade, since for example the build JDK can a totally different one, or wouldn't impact say a ruby/C/whatever compiler anyway.

Btw, I guess we own at least of those AIX installs, and JDK are actually generally not so that behind. JDK8 for AIX seems to be not GA *yet* but I'm sure IBM is working on it if not already out (found http://www.ibm.com/developerworks/java/jdk/beta/ for example).

Sure, old platform like AIX 4 or 5.x wouldn't have those JDK supported, so I suppose there could be some Jenkins VeryLTS to keep Java 6 as it's now for say some months or even a year for only very important issues. That would give time for those platform a bit more time to provide the JDK8 port/version for their OS.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor ! nbsp;!

[Nigel Magnay]

It is also not just so called esoteric OSes that do not have Java8. Take Ubuntu for example. The current latest release 14.04 still doesn't have Java8 as a native package. IIUC you currently have to rely on installing it from somebody's private repository (and I have no way of trusting these guys.) This means our DEB package will not be installable on its own. 

​Or, just download & unarchive it from oracle.com. 

​ 

Here's another one. IBM still hasn't released JDK8. If you are an IBM shop and need to use IBM JDK for support contracts, you'll be left behind.

You'll be waiting a long time if you're expecting that to change. ​I've got customers whose IBM 'support contracts' make them claim things like they can only run JDK1.4.

That's fine. They should stick on a support branch that keeps them happy, if that's the case (and, I'd expect, pay fees to a Jenkins shop to fix the tickets they raise). But I don't see why the rest of us should be dragged down to their lowest-common denominator behaviour - because 2% of the install base can't (or, more likely, doesn't want to exert any effort to) change, I have to write all my code (that I'm giving away for free) using stone knives and bearskins. Not terribly appealing for those of us doing it 'for fun'.

[nicolas de loof]

2014-09-24 21:55 GMT+02:00 Nigel Magnay <nigel....@gmail.com>:

It is also not just so called esoteric OSes that do not have Java8. Take Ubuntu for example. The current latest release 14.04 still doesn't have Java8 as a native package. IIUC you currently have to rely on installing it from somebody's private repository (and I have no way of trusting these guys.) This means our DEB package will not be installable on its own. 

​Or, just download & unarchive it from oracle.com. 

Sure, Jenkins JDK ToolInstaller do this already, the DEB/RPM installer could do the same, that's just a curl command with accept license header set.

 

​ 

Here's another one. IBM still hasn't released JDK8. If you are an IBM shop and need to use IBM JDK for support contracts, you'll be left behind.

You'll be waiting a long time if you're expecting that to change. ​I've got customers whose IBM 'support contracts' make them claim things like they can only run JDK1.4.

That's fine. They should stick on a support branch that keeps them happy, if that's the case (and, I'd expect, pay fees to a Jenkins shop to fix the tickets they raise). But I don't see why the rest of us should be dragged down to their lowest-common denominator behaviour - because 2% of the install base can't (or, more likely, doesn't want to exert any effort to) change, I have to write all my code (that I'm giving away for free) using stone knives and bearskins. Not terribly appealing for those of us doing it 'for fun'.

[Russ Tremain]

+1

I think it is fine to "allow java 8" but not require it.

Requiring the latest version of java to run Jenkins just means that many shops will stop upgrading Jenkins.

Compared to whatever new esoteric language features JDK8 has, stability of the Jenkins production platform concerns far outweigh convenience or curiosity concerns for Jenkins developers.

To put it graphically:

Production platform stability:  whale

Jenkins developer convenience:  anchovy

So that's my vote.  ;)

[Mark Waite]

I agree with Russ.  If we require Java 8, rather than just allowing it, we'll cause many users to stop upgrading their Jenkins installations, and will tend to lose their involvement in the project.

I appreciate developer benefits very much, but with 80 000+ installations, I think preserving compatibility is more valuable than the developer benefits of requiring Java 8.

I admit that I was just hit by exactly this condition as a developer.  I added a new test to the git client plugin which depended on a Java 7 NIO feature.  It failed to compile in my test configuration with Java 6.  Even so, I still think that the most we should require is Java 7.

Is there a way to count the summarize the distribution of virtual machines used with Jenkins today, similar to the summary posted earlier about platforms used with Jenkins?

Are there ways we could allow more of the benefits of Java 8 development, while still retaining compatibility?

Mark Waite

On Wed, Sep 24, 2014 at 4:48 PM, Russ Tremain <ru...@releasetools.org> wrote:

+1

I think it is fine to "allow java 8" but not require it.

Requiring the latest version of java to run Jenkins just means that many shops will stop upgrading Jenkins.

Compared to whatever new esoteric language features JDK8 has, stability of the Jenkins production platform concerns far outweigh convenience or curiosity concerns for Jenkins developers.

To put it graphically:

Production platform stability:  whale

Jenkins developer convenience:  anchovy

So that's my vote.  ;)

At 12:23 PM -0700 9/24/14, Kohsuke Kawaguchi wrote:

--

Thanks!

Mark Waite

[Craig Rodrigues]

On Wed, Sep 24, 2014 at 3:46 AM, nicolas de loof <nicolas...@gmail.com> wrote:

Lack of a recent JDK on some exotic systems (*) was already a blocker for Java 6 upgrade, that's a real issue, but on the other side we can't stuck to java 5 just because SCO-Unix don't have a better JDK. 

As suggested by Dominik, I think starting a 2.x branch to require java 8 would make sense. Springframework major releases were driven by minimal JDK updates, for the same reason, as this is the main compatibility breaker form a user point of view.

(*)  I wonder anyone tried to build OpenJDK on those platforms, even not officially supported

I don't know if you consider it exotic, but FreeBSD is definitely an "unsupported" platform, but OpenJDK 6, 7, and 8 have been ported to it.

I operate https://jenkins.freebsd.org which is running Jenkins on OpenJDK 7, on FreeBSD 9 and FreeBSD 10.

--

Craig

[nicolas de loof]

just using Java 8 (i.e. use some new API that do a better job) could help, but doesn't need a debate, we already do this for a while. 

Requiring Java 8 would allow some major change in jenkins design, especially on the way we extend base classes, and define API (as inner classes) vs lambdas

[Arnaud Héritier]

If we are talking about Java 8 only for a Jenkins 2.x (thus with a real cleanup, renew of the codebase and thus an adaptation/rewrite of plugins) it won't land before 1 year ? 2 years ? (at least to be stable / LTS)

I think that in one or 2 years J8 should have more supported environments ...

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[nicolas de loof]

I don't think we would have actual effort to refactor/cleanup codebase until such a java 8 / 2.x version becomes the actual mainstream version.

[Mirko Friedenhagen]

You mean when Java 8 is past it's EOL, Java 9 is current and 10 in beta ;-)

Regards
Mirko
--
Sent from my mobile

[Jesse Glick]

On Wed, Sep 24, 2014 at 8:47 PM, Mark Waite <mark.ea...@gmail.com> wrote:
> I added a new test to the git client plugin which depended on a Java 7 NIO
> feature. It failed to compile in my test configuration with Java 6.

I think it is fine to require Java 7 in tests; there was already a
proposal which met with no controversy to require 7 for building
plugins, while continuing to use -target 6 and Animal Sniffer to
prevent accidental use of 7+ APIs or bytecode (*). Requiring 8 for
building plugins, and thus allowing -source 8 features in
src/test/java/**/*.java (**), would be a natural next step, a bit
controversial but much less so than requiring 8 for running Jenkins
itself.


(*) Of course this means functional tests do not find runtime problems
occurring on 6 despite lack of linkage errors. But the alternative of
running tests on 6 just means the reverse problem, that behavioral
changes in 7 which break the plugin are not caught; and this is worse,
since many more people will really be running on 7.

(**) The upcoming version of Animal Sniffer allows you to skip checks
on test-scope dependencies. But it might not yet allow checks to be
skipped on src/test/java/**/*.java, which is not a dependency; will
need to look into it.

[James Nord]

Rejoice! IBM AIX and z/OS now have a GA Java8 version.

http://www-01.ibm.com/support/docview.wss?uid=swg21696670

Is it time to revisit this once more?

/James

[Stephen Connolly]

I think we could start looking at requiring Java 7 as a minimum for Runtime of Jenkins... given that Maven 3.3.1 has moved its minimum runtime to Java 7... if we want to bump the evil plugin version to use the Maven 3.3.1 embedded jars we will have to bump Jenkins to require Java 7 as a minimum... never mind that Java 7 goes EOL next month

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/c7fd3bd4-26f6-488f-a4bc-52bbf0a8dbad%40googlegroups.com.

[nicolas de loof]

As said when I opened this topic, I can't see major benefit in requiring Java 7 from a developer point of view (some syntactic sugar, few new API, what else ?), compared to huge benefit of Java 8 to review API design and extensibility

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMy1JAFugQHay92Uj1WA%3DZF_uBOQcWQ%3DYWjKa0bJLm9n2w%40mail.gmail.com.

[Stephen Connolly]

Well jumping from Java 6 to Java 8 is a big jump. My point is that we probably can strongly argue to jump to Java 7 today... then in a few months (say 3 months after Java 7 is EOL... to allow for an LTS that supports Java 7 but not Java 6) then we bump up to Java 8 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznmy08LYOn0VPMg%2Bkef84LCP72NhJakbKKKeqfiXD3DSw%40mail.gmail.com.

[Daniel Beck]

How's availability of Java 8 (and preferably JDK 8 for the tools) on the default package repos of the various platforms we have native packages for?

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwg-0TN7vSNf3o26X3%2BQTM4S2e90siEqQJPku78JUBokw%40mail.gmail.com.

[Kanstantsin Shautsou]

Java 7 has better file API and jenkins should have better performance. Also this should allow cleanup stab that do conditioning 6 vs 7 for some parts of code. Some libraries already start requiring java 1.7. If 1.6 is EOL then i'm +1 for switching to 1.7 as base line.

[James Nord]

I think multi-catch and try with resources are big enough on their own to take advantage of in java 7 :-)

The syntactic sugar of numerical literals with underscores, and the generic type inference although sugar will make code more readable.

As for Java8 bringing usefull things, streams to those that aren't in the know can create very under-performing code when used ([in]correctly) at scale and Lambdas despite Jesse's love of them are a half baked implementation that is oft (ab)used to create unintelligible code and the time API doesn't bring much that we couldn't do if we adopted JodaTime.

+1 to get the next LTS as Java7 only and the one after as Java8 only.

On Tuesday, 24 March 2015 10:42:02 UTC, nicolas de loof wrote:

As said when I opened this topic, I can't see major benefit in requiring Java 7 from a developer point of view (some syntactic sugar, few new API, what else ?), compared to huge benefit of Java 8 to review API design and extensibility.

[James Nord]

I have always seen those packages as a convenience and never anything that was to read into any supportability - especially given that they don't (didn't) set dependencies correctly and install files to completely inappropriate locations.  (there is a linux FHS for a reason).

So given that, my answer would be I don't care if CentOS 5 doesn't have a JDK8 in its distribution packages as there is an RPM from Oracle if people insist on doing it this way (which actually leads to a buggy Jenkins install which miss-behaves in ways users don't expect!).  On top of that the OpenJDK version 6 which ships with some OS'es that may currently be used is buggy as hell, so anyone that uses that is just asking for trouble at present.

/James

[Suckow, Thomas J]

While the initial thought of doing it in steps over the next two LTS's sounds nice, after pondering it more I don't think we need the added fragmentation. Changing to 7 or 8 will require me to install a "legacy" Jenkins for me to build on a system that barely has Java 6. I might as well bundle Java7 slaves into that and not end up with three Jenkins installs.

I don't know of any plugins that currently use Scala, but moving to Java8 would help from deterring them since they are moving to Java8.

-

Thomas

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/030973cc-703d-4314-80b9-a83a1693b3f4%40googlegroups.com.

[Jesse Glick]

On Tue, Mar 24, 2015 at 6:41 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> I can't see major benefit in requiring Java 7 from a developer point of view (some syntactic sugar, few new API

java.nio.file.* is actually rather important for Jenkins code,
particularly in core, since it uses the filesystem so heavily.

[Richard Bywater]

+1 for Java 7, -1 for Java 8 (at this time). Reason for that is that I don't believe there is any "normal" way for RHEL5 servers to get Java 8 and it will not be hitting its "end of production" phase until March 2017 and so I'm guessing there's still a lot out there.

Richard.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1%2BwP_j6S7_RtoLH_SYTjdO8Bs-QxEod520hhe5xKv7AQ%40mail.gmail.com.

[Kanstantsin Shautsou]

Sorry, but rhel5 is not something that we should care about, AFAIR it on extended support. You can still use ancient jenkins version and ask RHEL support to do patches for jenkins. RHEL6 and RHEL7 were released long time ago - update your infra.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sw_WepGw0Pk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui9471xSn_NknofC4H%2BaScs_j7oi%2B%2BpJcvEsz59CYgX81jdA%40mail.gmail.com.

[Richard Bywater]

I'm sorry but yet again you appear to be taking a very rude attitude with other community members with basically "your opinion does not matter".

Last time I checked I was part of the *we* by being part of the community and simply saying update your infrastructure trivialises the situation for what is possibly a reasonable user base of Jenkins.

Java 7 is not even end of lifed yet and so I'm wondering what the compelling argument for Java 8 is. That is, what features does it enable that will drive Jenkins to the next level?

Richard

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2EDF677B-14F1-478C-A2D5-4BC1514AAB06%40gmail.com.

[Kanstantsin Shautsou]

Ok, s/we/imho/ . Btw, there should be somewhere statistics. Let’s check how many RHEL5 installation jenkins has. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui947O1Bfx%2Bf%2B%2BL3U%2BsfYnBnqMJqUkS5oRSf-dhNbTcFs5ZA%40mail.gmail.com.

[Christopher Orr]

I don't share the opinion about the native packages being somehow not
for "real" use or being unsupported. Given that the packages are listed
prominently on the home page, and no statement of "install at your own
risk; these are possibly broken" is given, as a user I would have no
reason to assume that the packages are not well supported.

It's a shame we don't have any download stats for the native packages.
At least on Debian (for people who have opted in to package tracking),
there's fairly linear growth in package usage:
https://qa.debian.org/popcon-graph.php?packages=jenkins

The stats for Ubuntu look very similar.

Regards,
Chris

On 24/03/15 06:09, James Nord wrote:
> I have always seen those packages as a convenience and never anything
> that was to read into any supportability - especially given that they
> don't (didn't) set dependencies correctly and install files to
> completely inappropriate locations. (there is a linux FHS for a reason).
>
> So given that, my answer would be I don't care if CentOS 5 doesn't have
> a JDK8 in its distribution packages as there is an RPM from Oracle if
> people insist on doing it this way (which actually leads to a buggy
> Jenkins install which miss-behaves in ways users don't expect!). On top
> of that the OpenJDK version 6 which ships with some OS'es that may
> currently be used is buggy as hell, so anyone that uses that is just
> asking for trouble at present.
>
> /James
>
> On Tuesday, 24 March 2015 10:58:07 UTC, Daniel Beck wrote:
>
> How's availability of Java 8 (and preferably JDK 8 for the tools) on
> the default package repos of the various platforms we have native
> packages for?
>
> On 24.03.2015, at 11:52, Stephen Connolly <stephen.al...@gmail.com

> <javascript:>> wrote:
>
> > Well jumping from Java 6 to Java 8 is a big jump. My point is
> that we probably can strongly argue to jump to Java 7 today... then
> in a few months (say 3 months after Java 7 is EOL... to allow for an
> LTS that supports Java 7 but not Java 6) then we bump up to Java 8
> >
> > On 24 March 2015 at 10:41, nicolas de loof <nicolas...@gmail.com

> <javascript:>> wrote:
> > As said when I opened this topic, I can't see major benefit in
> requiring Java 7 from a developer point of view (some syntactic
> sugar, few new API, what else ?), compared to huge benefit of Java 8
> to review API design and extensibility
> >
> > 2015-03-24 11:36 GMT+01:00 Stephen Connolly

> <stephen.al...@gmail.com <javascript:>>:

> > I think we could start looking at requiring Java 7 as a minimum
> for Runtime of Jenkins... given that Maven 3.3.1 has moved its
> minimum runtime to Java 7... if we want to bump the evil plugin
> version to use the Maven 3.3.1 embedded jars we will have to bump
> Jenkins to require Java 7 as a minimum... never mind that Java 7
> goes EOL next month
> >
> > On 24 March 2015 at 10:33, James Nord <james...@gmail.com

> send an email to jenkinsci-de...@googlegroups.com <javascript:>.

> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c7fd3bd4-26f6-488f-a4bc-52bbf0a8dbad%40googlegroups.com

> <https://groups.google.com/d/msgid/jenkinsci-dev/c7fd3bd4-26f6-488f-a4bc-52bbf0a8dbad%40googlegroups.com>.

>
> >
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

> >
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it,

> send an email to jenkinsci-de...@googlegroups.com <javascript:>.

> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMy1JAFugQHay92Uj1WA%3DZF_uBOQcWQ%3DYWjKa0bJLm9n2w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMy1JAFugQHay92Uj1WA%3DZF_uBOQcWQ%3DYWjKa0bJLm9n2w%40mail.gmail.com>.

>
> >
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

> >
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it,

> send an email to jenkinsci-de...@googlegroups.com <javascript:>.

> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznmy08LYOn0VPMg%2Bkef84LCP72NhJakbKKKeqfiXD3DSw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznmy08LYOn0VPMg%2Bkef84LCP72NhJakbKKKeqfiXD3DSw%40mail.gmail.com>.

>
> >
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

> >
> >
> > --
> > You received this message because you are subscribed to the
> Google Groups "Jenkins Developers" group.
> > To unsubscribe from this group and stop receiving emails from it,

> send an email to jenkinsci-de...@googlegroups.com <javascript:>.

> > To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwg-0TN7vSNf3o26X3%2BQTM4S2e90siEqQJPku78JUBokw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwg-0TN7vSNf3o26X3%2BQTM4S2e90siEqQJPku78JUBokw%40mail.gmail.com>.

>
> > For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

[nicolas de loof]

2015-03-24 20:59 GMT+01:00 Richard Bywater <ric...@byh2o.com>:

I'm sorry but yet again you appear to be taking a very rude attitude with other community members with basically "your opinion does not matter".

Last time I checked I was part of the *we* by being part of the community and simply saying update your infrastructure trivialises the situation for what is possibly a reasonable user base of Jenkins.

Java 7 is not even end of lifed yet and so I'm wondering what the compelling argument for Java 8 is. That is, what features does it enable that will drive Jenkins to the next level?

• Refactor API / extension points as @FunctionalInterface
  
• adopt closures vs anonymous classes
  
• replace abstract class extension mechanism with interface (and as such multi-inheritance support)
  
• + few new useful APIs

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMui947O1Bfx%2Bf%2B%2BL3U%2BsfYnBnqMJqUkS5oRSf-dhNbTcFs5ZA%40mail.gmail.com.

[Christopher Orr]

Yeah, since we're upgrading, it may as well be to Java 8 since it (seems
to be) be available for every OS we package for, and it would minimise
the pain for users, rather than splitting it across two updates.

I don't think we specify the required Java version in most of our native
package specs, and WAR users upgrading will have no way of knowing about
the Java requirement change, so we probably need to do a lot of user
education in advance.

Maybe we can have banners inside the web interface for one or two
releases in advance, warning about the impending Java version
requirement? Plus big red text in the changelog, articles on the blog,
Twitter etc.

Some banners on the website, wiki and issue tracker (as we sometimes do,
e.g. for donation or JUC advertising) would also be a good idea.

Regards,
Chris


On 24/09/14 12:40, Baptiste Mathus wrote:
> I'm absolutely +1 on the advantages on the programming model that
> defining a JDK8 as a minimum JDK would give us. And like Nicolas, I also
> think JDK7 is not really worth it as 8 is.
>
> And Jenkins is one of those tools that has somehow a lower barrier on
> that requirement upgrade, since for example the build JDK can a totally
> different one, or wouldn't impact say a ruby/C/whatever compiler anyway.
>
> Btw, I guess we own at least of those AIX installs, and JDK are actually
> generally not so that behind. JDK8 for AIX seems to be not GA *yet* but
> I'm sure IBM is working on it if not already out (found
> http://www.ibm.com/developerworks/java/jdk/beta/ for example).
> Sure, old platform like AIX 4 or 5.x wouldn't have those JDK supported,
> so I suppose there could be some Jenkins VeryLTS to keep Java 6 as it's
> now for say some months or even a year for only very important issues.
> That would give time for those platform a bit more time to provide the
> JDK8 port/version for their OS.
>
> 2014-09-24 19:42 GMT+02:00 Daniel Beck <m...@beckweb.net
> <mailto:m...@beckweb.net>>:
>
>
> On 24.09.2014, at 11:48, Martin Kutter <martin...@fen-net.de
> <mailto:martin...@fen-net.de>> wrote:
>
> > Just want to throw in that java 8 is not yet available on all platforms
> > (like AIX, HP-UX and probably some other less frequently used commercial
> > UNIXes).
>
> I checked the anonymous usage stats a few weeks ago:
> Out of 93,400 installs, we know the master's OS for 85,200 of them.
> 285 are AIX. 120 are HP-UX. 50 installs total on OpenBSD, Darwin,
> OS/400, z/OS and NetBSD.
>
> Not relevant enough IMO if the advantages are significant.
>
> I can provide the queries I used if anyone wants to verify these.

>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
> --

> Baptiste <Batmat> MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!

>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-de...@googlegroups.com>.

[Kanstantsin Shautsou]

I think jenkins can check java version on startup and print friendly message to log instead of some java related stacktraces.

> You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sw_WepGw0Pk/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5511CD16.6090302%40orr.me.uk.

[Daniel Beck]

On 24.03.2015, at 20:53, Kanstantsin Shautsou <kanstan...@gmail.com> wrote:

> Sorry, but rhel5 is not something that we should care about, AFAIR it on extended support. You can still use ancient jenkins version and ask RHEL support to do patches for jenkins. RHEL6 and RHEL7 were released long time ago - update your infra.

The problem with the Java version used to run Jenkins is that it needs to be available on whatever box your builds run on.

It's nice if you're only building products using the latest hype technology, and discard them as soon as they're done, or upgrade the technology stack in every iteration, but there are *many* companies that still need to maintain products originally developed a decade or more ago, and the tools to build them are just as old, and wouldn't properly run on current systems.

And it's simply not possible to update Jenkins (master) in isolation, the remoting model requires that all slaves use similar JREs, and satisfy the minimum requirements.

> Ok, s/we/imho/ . Btw, there should be somewhere statistics. Let’s check how many RHEL5 installation jenkins has.

If you're referring to the anonymous usage statistics, we only know that they're running Linux, and the CPU architecture (os.name and os.arch).

And again, it's likely not the "installations" of Jenkins (i.e. master) that are the problem, but the build nodes.

[nicolas de loof]

What prevent you to get JDK8 on slave to run the remoting agent, but use JDK installer to build your legacy JDK 1.1 application ?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/25005053-52C1-4F40-B722-2A69E5A64F4D%40beckweb.net.

[Daniel Beck]

On 24.03.2015, at 21:57, nicolas de loof <nicolas...@gmail.com> wrote:

> What prevent you to get JDK8 on slave to run the remoting agent, but use JDK installer to build your legacy JDK 1.1 application ?

The Maven Job Type :-)

Seriously though, is JDK 8 available for all platforms we currently advertise Jenkins runs on (minus Solaris which was dropped)?

[Christopher Orr]

I don't actually know how the startup / WAR extraction stuff works, but
I did wonder whether a Java 6-compatible piece of code could be run at
startup to print a "Jenkins now requires Java 8" warning to the console.

But in any case, we need to warn users well in advance of upgrading. A
lot of people won't be happy if they hit the upgrade button in the UI
only to find that Jenkins doesn't come up again.

[Kanstantsin Shautsou]

I know projects that uses ancient distros and the root problem is that they didn’t schedule/plan upgrades in time at all. They don’t want to do it and it easy for them to slow down any projects they want. I think CloudBees will be a good company for doing payed support for ancient platforms. I know already some plugins that require 1.7 and maintainers doesn’t want to waste their life time with dealing somebody internal company issues.  Btw some people still silently patches 1.509.X for their needs :)

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sw_WepGw0Pk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmtvFmMnMki7q6H-0NDLmsQVjuzuC2xexvc0hb204iCaQ%40mail.gmail.com.

[Kanstantsin Shautsou]

So another idea that “update button” should compare and warn about java versions if they planned to be changed :)

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5511D127.90609%40orr.me.uk.

[Henri Gomez]

Java 7 will be a good first move.

Add Java 8 is requirement roadmap for say, 6 months, time for CI teams to prepare themselves.

On Linux and Windows, it's easy to have Java 8, it's another story on older hardware/OS.

I would also suggest keep slave.jar Java 6 or 7 to make slaves running on outdated hardware/OS still available to users.

Many many teams have to deal with such platforms ;(

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/60304202-5AA7-43C3-83F4-828AC1ED9997%40gmail.com.

[nicolas de loof]

This is not just slave.jar, all callable serialized and sent to slave need to rely on same class format, so you can't keep slave 1.6 compatible

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALyUpY3G9kAbvGMWSOpTu96n8KsnSig%3DXdgxDvFFTFpcY6AAAg%40mail.gmail.com.

[nicolas de loof]

SpringFramework did switch to 2.0 as they dropped support for java 1.3 - no internal refactoring, just a "major version" upgrade to warn people about some significant change they need to consider with care.

    <mailto:martin.kutter@fen-net.de>> wrote:

    > Just want to throw in that java 8 is not yet available on all platforms
    > (like AIX, HP-UX and probably some other less frequently used commercial
    > UNIXes).

    I checked the anonymous usage stats a few weeks ago:
    Out of 93,400 installs, we know the master's OS for 85,200 of them.
    285 are AIX. 120 are HP-UX. 50 installs total on OpenBSD, Darwin,
    OS/400, z/OS and NetBSD.

    Not relevant enough IMO if the advantages are significant.

    I can provide the queries I used if anyone wants to verify these.

    --
    You received this message because you are subscribed to the Google
    Groups "Jenkins Developers" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to jenkinsci-dev+unsubscribe@googlegroups.com

    <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.
    For more options, visit https://groups.google.com/d/optout.

    --
    Baptiste <Batmat> MATHUS - http://batmat.net
    Sauvez un arbre,
    Mangez un castor ! nbsp;!

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to jenkinsci-dev+unsubscribe@googlegroups.com
<mailto:jenkinsci-dev+unsub...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sw_WepGw0Pk/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5511CD16.6090302%40orr.me.uk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5511D127.90609%40orr.me.uk.

[Suckow, Thomas J]

> What prevent you to get JDK8 on slave to run the remoting agent, but use
>JDK installer to build your legacy JDK 1.1 application ?

In many cases this is possible. I don't think this is documented all that
well though (I've done it once and it took me a while to get it right). I
would imagine this is something that should be in an upgrade guide. If you
can't run JDK8, then you get to run a legacy Jenkins install.

> Sorry, but rhel5 is not something that we should care about, AFAIR it on
>extended support. You can still use ancient jenkins version and ask RHEL
>support to do patches for jenkins. RHEL6 and RHEL7 were released long
>time ago - update your infra.

I don't think we should be making sure NEW release cycles support RHEL5.
It is in extended support, people in that environment should be
comfortable dealing with tools from that era. That said, there are ways to
make it work, but it shouldn't be blessed.

> And it's simply not possible to update Jenkins (master) in isolation,
>the remoting model requires that all slaves use similar JREs, and satisfy
>the minimum requirements.

But we shouldn't stay at Java6 forever. I am seeing a lot of hints at
making some radical changes/improvements. Should we really be talking of a
Jenkins2 and not expect people to auto-update to it? We could offer 1 or 2
more LTS on the 1.x track.

-
Thomas

[nicolas de loof]

2015-03-24 22:38 GMT+01:00 Suckow, Thomas J <Thomas...@pnnl.gov>:

> What prevent you to get JDK8 on slave to run the remoting agent, but use
>JDK installer to build your legacy JDK 1.1 application ?

In many cases this is possible. I don't think this is documented all that
well though (I've done it once and it took me a while to get it right). I
would imagine this is something that should be in an upgrade guide. If you
can't run JDK8, then you get to run a legacy Jenkins install.

Didn't you just configured a JDK installation and select it from your job configuration ?

 

> Sorry, but rhel5 is not something that we should care about, AFAIR it on
>extended support. You can still use ancient jenkins version and ask RHEL
>support to do patches for jenkins. RHEL6 and RHEL7 were released long
>time ago - update your infra.

I don't think we should be making sure NEW release cycles support RHEL5.
It is in extended support, people in that environment should be
comfortable dealing with tools from that era. That said, there are ways to
make it work, but it shouldn't be blessed.


> And it's simply not possible to update Jenkins (master) in isolation,
>the remoting model requires that all slaves use similar JREs, and satisfy
>the minimum requirements.

But we shouldn't stay at Java6 forever. I am seeing a lot of hints at
making some radical changes/improvements. Should we really be talking of a
Jenkins2 and not expect people to auto-update to it? We could offer 1 or 2
more LTS on the 1.x track.

What would change in 3/ 6 months ?

Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications. 

 

-
Thomas

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D1372128.11495%25thomas.suckow%40pnnl.gov.

[Suckow, Thomas J]

> Didn't you just configured a JDK installation and select it from your job configuration ?

Ya. Once I know how that works. I didn't expect it to be a global jenkins configuration when I only have that setup on a single slave. Maybe I am a bit slow. I also configured the slave to start with the desired jdk and was surprised when the job didn't use that same slave.

But we shouldn't stay at Java6 forever. I am seeing a lot of hints at
making some radical changes/improvements. Should we really be talking of a
Jenkins2 and not expect people to auto-update to it? We could offer 1 or 2
more LTS on the 1.x track.

What would change in 3/ 6 months ?

Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications. 

Ok, maybe 10 LTS's then. We need to have a plan for supporting the past and the future.  If we do have so many people wanting the java6 branch, then they should be able to support it. It sounds like we have a large number of people interested in java8 and I don't think such a transition will be ready for quite some time. I imagine we will also have people using both and maintaining both. I still have RHEL5 and a SPARC and I will do what I have to with those as long as I need to. But I also have bleeding edge items and I'd like to see Jenkins continue to push that envelope. This is a community, I can't imagine that if the mainline moved on to Java8 we wouldn't still help those who are still using the current mainline.

-

Thomas

[nicolas de loof]

Proposal is not to maintain parallel branches, but to make next release to require Java 8 and start using it for new development / step by step enhance existing APIs to benefit Java 8

 

What would change in 3/ 6 months ?

Lot's of people will still run RHEL 5 and build legacy Java 1.3 applications. 

Ok, maybe 10 LTS's then. We need to have a plan for supporting the past and the future.  If we do have so many people wanting the java6 branch, then they should be able to support it. It sounds like we have a large number of people interested in java8 and I don't think such a transition will be ready for quite some time. I imagine we will also have people using both and maintaining both. I still have RHEL5 and a SPARC and I will do what I have to with those as long as I need to. But I also have bleeding edge items and I'd like to see Jenkins continue to push that envelope. This is a community, I can't imagine that if the mainline moved on to Java8 we wouldn't still help those who are still using the current mainline.

-

Thomas

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/D13733B8.11501%25thomas.suckow%40pnnl.gov.

[Nigel Magnay]

I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions:

Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes, it's not EOL - it's probably what most people are actually building products on. Indeed Tomcat 6 still gets fixes. But 'new development' is happening elsewhere.

In the context of 'LTS', I don't think it's acceptable to simply bump a heap of external requirements; if I were on a maintenance contract, I'd yell too! A Jenkins 1.xxx line should continue to receive fixes (e.g security, critical bugs, whatever else the community finds). A Jenkins 2.xxx line should take the opportunity to upgrade to JDK8 (and perhaps bump up some libraries like guava while it's at it).

The argument I hear, and I think it's possibly a straw man, is a demographic of users who are 'stuck on <slow coach platform>' who go beyond demanding support (which I think they deserve), but also want all the new features as well.

If they truly exist (perhaps they do, but it seems an odd combination of being unable to change anything about their environment except the version of Jenkins they run), then I find that position phenomenally presumptuous. What they are demanding is what I develop (for free! and give away to them!) must forever be tied to their lowest-common-denominator platform, representing an utterly tiny minority. Now that Java itself is also OSS (and virtualisation is a thing, and hardware is cheap, etc etc), this is never a "we can't change", it's simply a "we don't want to". Put simply, new features available on a new product version usually builds the business case for making an environmental change. But why bother doing that, when you can transfer the burden of doing that back to the unpaid, OSS developers giving me product for free?

On the technical, Java8 brings some useful stuff, and is a more pleasant and modern place for a developer:

- No more permgen space!

- Default methods in interfaces (useful when you're trying to extend an API throughout the life of a product)

- Lambda Expressions

- Optional<T>

- Method parameter names in metadata (I believe Jenkins needs a plugin to extract this. Certainly that's the approach I needed pre-JDK8, which often failed when my IDE decided to recompile - good riddance to that).

In the context of recruiting (OSS) developers, I think Java moves slowly enough (especially cf. C#) to damage its mindshare without additionally making it all less fun by making everyone act like a corporate IT developer stuck on an obsolete platform. That just drives people to work on CI systems that don't have that constraint.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJznBdm3DmnZ_GO0viCawUek0yXj3jnSiZR%3DoDpHObR%2BSvQ%40mail.gmail.com.

[Stephen Connolly]

On 25 March 2015 at 07:49, Nigel Magnay <nigel....@gmail.com> wrote:

I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions:

Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes, it's not EOL - it's probably what most people are actually building products on. Indeed Tomcat 6 still gets fixes. But 'new development' is happening elsewhere.

In the context of 'LTS', I don't think it's acceptable to simply bump a heap of external requirements; if I were on a maintenance contract, I'd yell too! A Jenkins 1.xxx line should continue to receive fixes (e.g security, critical bugs, whatever else the community finds). A Jenkins 2.xxx line should take the opportunity to upgrade to JDK8 (and perhaps bump up some libraries like guava while it's at it).

I think for build tools, such as Jenkins/Maven/Ant/Gradle/etc, there are basically two JDK requirement modes that make sense:

* one and one back

* all the JDKs currently supported by Oracle

Right now the first says JDK7 & JDK8 and the second says JDK7 and JDK8.

JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8.... but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL.

The advantage of the second model is that the July LTS will be JDK8

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83SEJxm%2BfSaJF192TjWWszB6Cjq2XS4ToXi0ztnyyoUvyA%40mail.gmail.com.

[Nigel Magnay]

JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8.... but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL.

The advantage of the second model is that the July LTS will be JDK8

​So it could be there's some confusion around "LTS"​, as the wiki says it follows the ubuntu model, but is it really the same?

I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap).

​If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for 5 years. It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already).

So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years.

Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks.

12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ?

Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else.

I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n>3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you.

​

 

[Stephen Connolly]

On 25 March 2015 at 09:20, Nigel Magnay <nigel....@gmail.com> wrote:

JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8.... but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL.

The advantage of the second model is that the July LTS will be JDK8

​So it could be there's some confusion around "LTS"​, as the wiki says it follows the ubuntu model, but is it really the same?

No I don't think it is even close to the same 

I.E: If I use Ubuntu 14.10, I'll basically get updates for 9 months, after which if I want a fix, I'll have to flip to 15.04 (There's an overlap).

​If I want stability, I pick an LTS version (released every 2 years) - 14.04 LTS - which is supported for 5 years. It gets no new features in that time, but it does receive updates (indeed we're up to 14.04.2 already).

So ubuntu is a release every 6 months, an LTS release every 2 years, with LTS 'support' for 5 years.

Jenkins is a release ~every week, an LTS release every 12 weeks, with LTS 'support' for 12 weeks.

That is all that the community has stepped up to deliver. I have no issue if the community wants to put effort into maintaining older LTS lines in addition to the current LTS, but that is something that the community needs to decide. 

 

12 weeks seems like a very short period of 'support'. Trying to put myself in the shoes of 'corporate IT world', isn't that saying that if I build my infra (and JDK) around Jenkins 1.xxx.1 - I'll get only 12 weeks grace before the possibility that a security fix might mean I need to change my JDK ?

The 'corporate IT world' would really want a 10 year cycle if it could get it ;-)

 

Now - I am perfectly comfortable with that (indeed we step our environment to match the Jenkins LTS editions), but I can see that a side-effect might be those with conservative environments trying hard to make sure that when the 'version with the fix' comes around, basically trying torpedo JDK8 or anything else.

Which is why I think going for JDK7 now is a better plan than trying to jump all the way to JDK8

 

I'm also perfectly comfortable with the possibility that if you need Jenkins 1.xxx.(n>3), then you obtain those by either contributing the backporting effort yourself, or having a maintenance contract with Cloudbees|A.N.Other that does it for you.

​

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPYP83ROco9JLBT8Vthi3YEpNEjLWQtqxkdvjiWzaJPp28u0bg%40mail.gmail.com.

[James Nord]

I didn't mean to kick up this much of a shit storm!

People have their opinions but we need to move forward to reach a decision of which there is not one solution that meets everyone's requirements.

What is the next steps here?  

• Do we vote on the following options:
  
1. Support the current and previous verions of the Oracle JDK
   
2. Support the JDKs that Oracle support
3. do nothing and stick with Java6.
• Is this something for the governance board to decide at the next meeting?

/James

[nicolas de loof]

The underlying question is indeed to determine project rules considering supported runtime

1. Support the current and previous verions of the Oracle JDK
   
2. Support the JDKs that Oracle support

1. do nothing and stick with Java6 until 2020.

We already decide to move from 1.5 to 6, and this had some impacts on existing installation, but afaik there's not so much people stuck on jenkins 1.519 ! About upgrade warning, we had 

Can offer a page comparable to https://wiki.jenkins-ci.org/display/JENKINS/Java+5+Compatibility

Requirement to run Java 7 will force some users to upgrade infra, so we already can prepare for complains. As I don't like to receive complains, I'd prefer to upgrade to a JDK which offer actual new programmation options, not just new filesystem API (that we use via XMLFile anyway)

so I vote for option 2

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/308a1894-e1df-4c3f-b43e-19c2e5133399%40googlegroups.com.

[Daniel Beck]

> • Is this something for the governance board to decide at the next meeting?

Next meeting's agenda is already more than full.

> People have their opinions but we need to move forward to reach a decision of which there is not one solution that meets everyone's requirements.

We should know what the side effects are though (including JDK availability on the systems our users use), and communicate accordingly. Right now, I don't even know how availability of JDK 8 is for various common platforms Jenkins runs on.

If increasing the JDK requirement means we need to discontinue some of the native installers, then that's fine with me in principle, if we know in advance and can plan accordingly (e.g. provide extensive 'manual installation' instructions). But increasing the system requirements such that the installers simply become useless would hurt users who rely an them and rightfully expect them to work*. They exist and are essentially the recommended way to install Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins), so we should support them, and fix their shortcomings, rather than ignore them. Jenkins is difficult enough to start using as it is. Let's not make it worse.

Why don't we start by setting up a configuration survey, asking the users list, and putting banners up on the wiki, Jira, jenkins-ci.org? Then we'd at least have some data to base any decisions on.

[Jesse Glick]

On Wed, Mar 25, 2015 at 7:55 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> new programmation options, not just new filesystem API (that we use via XMLFile anyway)

To be clear, there is code scattered all over Jenkins core (and some
plugins) which would benefit significantly from java.nio.file. (In a
few such cases we are actually already using Java 7 APIs via
reflection when available. In most cases we are not because it is too
painful.)

BTW a much more conservative proposal was made (by me?) a few months
ago: that the Jenkins (core + plugin) _build requirement_ be switched
to JDK 7+. src/main/java/ would remain compiled with -source 6 (so no
<>, try-with-resources, etc.) but could use Java 7-only APIs without
reflection, only guarded by Animal Sniffer (isolated in methods marked
@IgnoreJRERequirements). Doing that for JDK 8 is not terribly useful
since so many of the new APIs require -target 8. It was also proposed
that src/test/java/ could switch to -source 8 and use Java 8 APIs, to
make writing tests more pleasant even when the main sources are stuck
on 6, though it has since been pointed out that while Maven supports
this style without issue, IntelliJ cannot handle it. (NetBeans handles
it; not sure about Eclipse.)

[Jesse Glick]

On Wed, Mar 25, 2015 at 6:53 AM, Stephen Connolly
<stephen.al...@gmail.com> wrote:
> Which is why I think going for JDK7 now is a better plan than trying to jump
> all the way to JDK8

Painful as it is, I tend to agree. To be clear, by current LTS policy,
switching the baseline to Java 8 means that someone whose corporate IT
supports installation of only Java 7 will not receive even security
fixes in about three months. (CloudBees customers get an extra nine
months’ reprieve.) Otherwise they are left to backport for themselves.

[James Nord]

But they will have a JDK that won't get security fixes in less time than this unless they have some commercial support - so I don't get what your point is here?

[Richard Bywater]

Not entirely true - Redhat customers will get until at least November (so a further 6 months) and even after that the company could be paying Oracle for extended support.

Richard.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bfbcba82-cb58-43b4-a763-77b326662a9b%40googlegroups.com.

[James Nord]

You misread and 100% agreed with what I originally said :-)

"...they will have a JDK that won't get security fixes in less time than this unless they have some commercial support"

Getting fixes from RedHat requires an active licence/support agreement, ditto for Java SE for business.

[Richard Bywater]

D'oh - sorry, no idea how I missed those words. Guess that's what comes of replying to emails at 11pm...

Richard

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4d65da98-f640-448f-b4f8-ee45b1872ef9%40googlegroups.com.

[Stephen Connolly]

The point is that right now people can get security fixes for JDK7. Thus the code base *right now* cannot abandon JDK7.

The next LTS will be picked from a Jenkins tip set up in the next couple of weeks - i.e. while JDK7 is still "supported for free" by Oracle.

This means that the best we can do *before May 2015* is move to JDK7... IOW drop support for the well end of life JDK6.

On 1st of May 2015 we move Jenkins HEAD to JDK8 because only JDK8 is supported by Oracle. That means that May's LTS is JDK7 *because it was based off a HEAD version that was released while JDK7 was supported by Oracle*

The LTS line after May will thus be JDK8 only.

After 1st May 2015, anyone running JDK7 will only be getting JDK security fixes if they have a commercial agreement with Oracle or some other vendor, and thus if they want to continue getting security fixes for the last JDK7 line of Jenkins then they have three options:

* Contribute to the community by forming a sub-group in the community that does the back-ports. That sub-group would likely want to ask to be signed up to the security-cert list so that they can coordinate.

* Do the back ports themselves in a mad panic on the day the changes are released (i.e. I don't think you'll get on the security-cert private list if you are not contributing to the community in some shape or form, or unless you are providing commercial support for Jenkins) 

* Pay somebody else to provide the support (somebody who is providing commercial support for Jenkins IMHO should be able to get on the security-cert private list even if they are not contributing to the community... I do not view CloudBees as being special in this regard... my personal belief is that if you are providing Jenkins support or providing Jenkins as a Service, you should be contributing to the security-cert effort as a matter of course. I know KK has reached out to a number of other vendors to try and get them involved)

Which option they choose is their business 

-Stephen

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/bfbcba82-cb58-43b4-a763-77b326662a9b%40googlegroups.com.

[nicolas de loof]

right, so the JDK 7 EOL mostly doesn't match our next LTS, 

so as we know a JDK switch will impact users, I suggest we postpone JDK upgrade to post-may LTS, then can adopt JDK 8 in June so the LTS we will select in July can be based on it.

Doing this, we will only enforce jenkins user to upgrade JDK once, and still can move forward in a reasonable delay.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwj15gcdd9phhRSMGKVWCtemCN4UVbDVe4UY9xpe-ZAsQ%40mail.gmail.com.

[Stephen Connolly]

I'm going to try the "code walks" approach.... here is my suggestion https://github.com/jenkinsci/jenkins/pull/1624

I'm sure that nicolas will complain about that one

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DRFvMOPn5BHQRSLEt33jMYJn1VveDtzx6NdcuM78G3OA%40mail.gmail.com.

[James Nord]

Nicolas, your logic is not correct in that we only force users to upgrade once.

Just because we would require JDK7 does not mean the user needs to install JDK7 and then JDK8 when we require JDK8.  They can (if their platform supports it) install JDK8 straight away and run Jenkins compiled for JDK7 on it, so they have only one upgrade.

If the platform does not support JDK8 then you save one upgrade -  how many people are in this situation is the question that may need answering.

Right now the OracleJDK 1.8 is supported on RedHat 5.5+ and most other mainstream OSes.

[nicolas de loof]

2015-03-26 12:57 GMT+01:00 James Nord <james...@gmail.com>:

Nicolas, your logic is not correct in that we only force users to upgrade once.

Just because we would require JDK7 does not mean the user needs to install JDK7 and then JDK8 when we require JDK8.  They can (if their platform supports it) install JDK8 straight away and run Jenkins compiled for JDK7 on it, so they have only one upgrade.

Those users are the one who follow jenkins ML and announcements. I'm considering here the one who will discover JDK requirement changed, then will complain and eventually upgrade JDK. Then few month later this would happen again

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/19b3df75-2446-459b-9780-9fab229bb5ac%40googlegroups.com.

[Stephen Connolly]

On 26 March 2015 at 12:06, nicolas de loof <nicolas...@gmail.com> wrote:

2015-03-26 12:57 GMT+01:00 James Nord <james...@gmail.com>:

Nicolas, your logic is not correct in that we only force users to upgrade once.

Just because we would require JDK7 does not mean the user needs to install JDK7 and then JDK8 when we require JDK8.  They can (if their platform supports it) install JDK8 straight away and run Jenkins compiled for JDK7 on it, so they have only one upgrade.

Those users are the one who follow jenkins ML and announcements. I'm considering here the one who will discover JDK requirement changed, then will complain and eventually upgrade JDK. Then few month later this would happen again

The good news is that if you are running Java 6 and you try to start Jenkins compiled for Java 7 it will blow up immediately, thus none of your data is lost and you can roll back quickly and easily... or upgrade to Java 7/8

If you are not testing upgrades before doing them then caveat emptor

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DhukO%3Durp_Nje0ZoU2vs4eiq%3DRqWQ0x-1yd0cMs0o2XA%40mail.gmail.com.

[nicolas de loof]

2015-03-26 12:55 GMT+01:00 Stephen Connolly <stephen.al...@gmail.com>:

I'm going to try the "code walks" approach.... here is my suggestion https://github.com/jenkinsci/jenkins/pull/1624

I'm sure that nicolas will complain about that one

indeed

here is mine https://github.com/jenkinsci/jenkins/pull/1625

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzy7EkKYAW6YgyPv0E5gzgwF8%2BGA-Ch%3DgeCg3e2jnf%3DHw%40mail.gmail.com.

[Stephen Connolly]

Get back to us when you have one that actually building

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzn1_43scQbbaQj_rQzA%3DcPOc4H%3DcT8rS7G5_t0OWOJGEA%40mail.gmail.com.

[Kanstantsin Shautsou]

PR failed ;)

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/sw_WepGw0Pk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzn1_43scQbbaQj_rQzA%3DcPOc4H%3DcT8rS7G5_t0OWOJGEA%40mail.gmail.com.

[James Nord]

Nicolas, your logic is not correct in that we only force users to upgrade once.

Just because we would require JDK7 does not mean the user needs to install JDK7 and then JDK8 when we require JDK8.  They can (if their platform supports it) install JDK8 straight away and run Jenkins compiled for JDK7 on it, so they have only one upgrade.

Those users are the one who follow jenkins ML and announcements. I'm considering here the one who will discover JDK requirement changed, then will complain and eventually upgrade JDK. Then few month later this would happen again

So how do those class of users find out that the JDK requirement has changed and what the new requirement is?  

If we have documented this in the change log and publicized this on the wiki and they don't ask on the normal support channels then to be brutally honest then I don't care.

If they use the package management to upgrade and don't check the change log - again I don't care.

Others do care about the native package - so for those that do care, one of them could step up and put in a pre-install script that spits out the new JDK requirement with suggestions about what to install (and that it will change again in 3 months).

Users that are not caught by any of the 2 above - we have no chance of helping anyway - so at which point I will say again I just don't care.

[nicolas de loof]

cause animal sniffer doesn't have a java8 signature bundle published.

http://repo1.maven.org/maven2/org/codehaus/mojo/signature/

ok, seems I'm in minority here, giving up

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5643391F-AB67-4CD6-9B57-E1495A03FEDD%40gmail.com.

[Jesse Glick]

On Thu, Mar 26, 2015 at 5:39 AM, James Nord <james...@gmail.com> wrote:
>> switching the baseline to Java 8 means that someone whose corporate IT
>> supports installation of only Java 7 will not receive even security
>> fixes in about three months.
>

> But they will have a JDK that won't get security fixes in less time than this

A valid point, though I am guessing that the great majority of Java
security fixes are not dealing with vulnerabilities that would
actually affect Jenkins (as opposed to JavaWebStart, other server
apps, etc.). IOW, using a fully patched Jenkins is far more important
than using the latest Java update. I have not managed to find a
single, clear list of recent Java security fixes, so it is hard to
tell for sure.

[James Nord]

Oracle aren't very forthcoming with details but the last big security pack (Jan 2015) contained CVE-2015-0410 which is marked remotely exploitable via the network. Whilst some things may not seem exploitable some plugins do things like image manipulation which has been exploitable in the past and will run on the master.

[Kohsuke Kawaguchi]

Now that hopefully the dust has settled, I don't think anyone is arguing for supporting Java6, so let's start by moving up the dependency to Java7.

The usual steps are to do these 3 things over a period of time:

• Announcement in the blog and users list to advertise that we are going to do this. (T0)
• Start producing new 51.0 class file images, without linking to new APIs. This gives a warning period for people not following our PR outlets to notice the hard way and complain. (T0+2 weeks)
• Animal sniffer check is lifted to allow Java7 APIs, and we get to a point of no return. (T0+6 weeks?)

2015-03-27 14:16 GMT-07:00 James Nord <james...@gmail.com>:

Oracle aren't very forthcoming with details but the last big security pack (Jan 2015) contained CVE-2015-0410 which is marked remotely exploitable via the network.  Whilst some things may not seem exploitable some plugins do things like image manipulation which has been exploitable in the past and will run on the master.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2a193d09-7090-4ae3-b7d5-3fa2fa6713d9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[Baptiste Mathus]

Kohsuke, I just read the whole thread, and I'm under the impression that there was also some kind of consensus to make JDK8 the basis in a second step.

So, shouldn't we reflect that by having in the T0 communications some kind of statement like "upgrading to JDK7 as min requirement now, and bump to JDK8 will certainly be considered in the upcoming months", so that users prepare themselves.

Btw, could/shouldn't we even recommend people to run Jenkins on a JDK8 if they can? That would help users to plan their upgrade more smoothly I guess.

FWIW, we've been running our Jenkins' "cluster" on JDK8 since January without any issue.

WDYT?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4wEqcXD2Pv%3D5CWy-5yhMFfJXbu7473hoqZvX-vr9anxtA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

nbsp;!

[nicolas de loof]

2015-03-28 7:25 GMT+01:00 Baptiste Mathus <m...@batmat.net>:

Kohsuke, I just read the whole thread, and I'm under the impression that there was also some kind of consensus to make JDK8 the basis in a second step.

So, shouldn't we reflect that by having in the T0 communications some kind of statement like "upgrading to JDK7 as min requirement now, and bump to JDK8 will certainly be considered in the upcoming months", so that users prepare themselves.

Good point, we should suggest user who have to upgrade infra to use JDK 8 just now if them can so they won't have to do this later

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5La2SCfN%2BwjdPr2y0W8ef9673GL97n1HPwLshUuHru4Q%40mail.gmail.com.

[Jesse Glick]

Certainly we should recommend Java 8 as the preferred runtime.

In general I think we should recommend the latest Java general release according to Oracle. That implies routinely testing against EA builds of the next line (9 currently) so that we are not caught unprepared by showstopper incompatibilities as happened with 8 (due to bytecode manipulation  libraries not handling new rt.jar properly, IIUC).

[nicolas de loof]

2015-03-28 11:01 GMT+01:00 Jesse Glick <jgl...@cloudbees.com>:

Certainly we should recommend Java 8 as the preferred runtime.

In general I think we should recommend the latest Java general release according to Oracle. That implies routinely testing against EA builds of the next line (9 currently) so that we are not caught unprepared by showstopper incompatibilities as happened with 8 (due to bytecode manipulation  libraries not handling new rt.jar properly, IIUC).

Agree. Added to my TODO to add a JDK 7/8/9 matrix build on jenkins.ci.cloudbees.com to test jenkins compat with current and future JDKs

 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3uo9Y-rTrqf-ucGf2mNNQ-fNCCYXYHxGReqVDeG%3DzC0g%40mail.gmail.com.

[nicolas de loof]

2015-03-28 11:16 GMT+01:00 nicolas de loof <nicolas...@gmail.com>:

2015-03-28 11:01 GMT+01:00 Jesse Glick <jgl...@cloudbees.com>:

Certainly we should recommend Java 8 as the preferred runtime.

In general I think we should recommend the latest Java general release according to Oracle. That implies routinely testing against EA builds of the next line (9 currently) so that we are not caught unprepared by showstopper incompatibilities as happened with 8 (due to bytecode manipulation  libraries not handling new rt.jar properly, IIUC).

Agree. Added to my TODO to add a JDK 7/8/9 matrix build on jenkins.ci.cloudbees.com to test jenkins compat with current and future JDKs

was simple enough so it went into my "fast" TODO list :P

https://jenkins.ci.cloudbees.com/job/core/job/JDK%20compatibility