[DISCUSS] Time for Jenkins to require Java 8 to run

1,286 views
Skip to first unread message

Baptiste Mathus

unread,
Oct 13, 2016, 8:30:11 AM10/13/16
to Jenkins Developers
Hey folks,

As we've been discussing that again on IRC recently, we thought it might be a good time to discuss that subject again. Latest thread about that I could find is already 18+ months old.

In the meantime, Java 7 has now long been EOLed since mid 2015 (see https://java.com/en/download/faq/java_7.xml for details).

Also, many if not all of us very often advise users to just use Java 8 everytime they can to run Jenkins. We use it to build Jenkins (though generating 7 bytecode).

Not EOLed, removed PermGen, Lambdas, Default Methods, etc., many reasons to update to JDK 8 from the Ops and Dev perspectives. 

IMO, it's time to move on. Jenkins can very easily use another JDK version for builds, so I don't think there're compelling reasons to keep supporting Java 7. 

The common argument that "big" companies won't then be able to use Jenkins anymore just does not hold IMO for at least two reasons: we know some very big shops just using Jenkins with Java 8 without any issue, and the most conservative companies are anyway, as always, probably still running already (very) old versions of Jenkins. They will just catch that train later.

WDYT?

-- Baptiste

Stephen Connolly

unread,
Oct 13, 2016, 9:35:49 AM10/13/16
to jenkin...@googlegroups.com
On 13 October 2016 at 13:29, Baptiste Mathus <m...@batmat.net> wrote:
Hey folks,

As we've been discussing that again on IRC recently, we thought it might be a good time to discuss that subject again. Latest thread about that I could find is already 18+ months old.

In the meantime, Java 7 has now long been EOLed since mid 2015 (see https://java.com/en/download/faq/java_7.xml for details).

Technically, at least on RHEL, OpenJDK 7 still has some legs


But then given that RHEL supports OpenJDK 6 until the end of this year and we have dropped support for Java 6 as of 1.610-ish (technically may be 1.612 that actually dropped support, and 1.609 was announced to not have support for Java 6, even though it did)... do we really care about that data point?

(IBM JDK is another story... there Java 6 is until 30-Sep-2018 and Java 7 is until 30-Sep-2019... but Jenkins does not really claim to support running in the IBM JDKs, so I am happy ignoring those for now)
 

Also, many if not all of us very often advise users to just use Java 8 everytime they can to run Jenkins. We use it to build Jenkins (though generating 7 bytecode).

Not EOLed, removed PermGen, Lambdas, Default Methods, etc., many reasons to update to JDK 8 from the Ops and Dev perspectives. 

IMO, it's time to move on. Jenkins can very easily use another JDK version for builds, so I don't think there're compelling reasons to keep supporting Java 7. 

The common argument that "big" companies won't then be able to use Jenkins anymore just does not hold IMO for at least two reasons: we know some very big shops just using Jenkins with Java 8 without any issue, and the most conservative companies are anyway, as always, probably still running already (very) old versions of Jenkins. They will just catch that train later.

WDYT?

I'm +1... but having had this battle over at Apache Maven several times now, I am well versed in the objections people come up with! ;-)

-Stephen
 

-- Baptiste

--
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/CANWgJS6%3D23HQ%3DmhRxxvzkWPba%2BpanO_fUGR90Y58Fvvax1aciA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Beck

unread,
Oct 13, 2016, 10:09:03 AM10/13/16
to jenkin...@googlegroups.com

> On 13.10.2016, at 15:35, Stephen Connolly <stephen.al...@gmail.com> wrote:
>
> Technically, at least on RHEL, OpenJDK 7 still has some legs
>
> https://access.redhat.com/articles/1299013
>
> But then given that RHEL supports OpenJDK 6 until the end of this year and we have dropped support for Java 6 as of 1.610-ish (technically may be 1.612 that actually dropped support, and 1.609 was announced to not have support for Java 6, even though it did)... do we really care about that data point?

RHEL 5 will leave regular support in March: https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle

RHEL 6 + 7 support Java 8. I don't see this particular distro as a problem. In general, availability of a supported (old) JRE doesn't mean we should't require something newer. Absence of a support (new) JRE would be the problem.

Martin Kutter

unread,
Oct 13, 2016, 10:59:08 AM10/13/16
to jenkin...@googlegroups.com
Hi,

According to http://www.oracle.com/technetwork/java/javase/
certconfig-2095354.html, Java 8 is supported for RHEL 5.5+

It is also available on IBM AIX and zOS, and on HP UX, where alternative JDKs
do not exist:

http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/welcome/
welcome_javasdk_version.html

https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?
productNumber=HPUXJDKJRE80


Martin


Nigel Magnay

unread,
Oct 13, 2016, 11:09:54 AM10/13/16
to jenkin...@googlegroups.com
Update already.

Those in bizarre AIX, zOS and HPUX universes can continue to use older Jenkins versions. 

Robert Sandell

unread,
Oct 13, 2016, 11:26:40 AM10/13/16
to jenkin...@googlegroups.com
I'm for it,
But didn't we discuss a new "deprecation policy" in the beginning of the Jenkins 2 planning, or did I dream that?
I'm mostly thinking of the rollout of this, many installations seems to have just dared to start thinking about upgrading to Jenkins 2, perhaps we shouldn't throw a Java upgrade in their face after just two LTS releases? Or maybe two is enough?

/B


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



--
Robert Sandell
Software Engineer
CloudBees Inc.

Baptiste Mathus

unread,
Oct 13, 2016, 11:30:49 AM10/13/16
to Jenkins Developers
Well, this thread is mostly IMO to see the trend/opinions to do it. 

We have not defined a timeline: we could probably for example issue a notice on the website that we'll do it on the first version of 2017, and then the next associated LTS after that date?

That would still give a few more time to people who are still running Jenkins on Java 7 to upgrade. And one or two more LTS with Java 7 (didn't check what the dates would give) in the meantime.

R. Tyler Croy

unread,
Oct 13, 2016, 11:53:33 AM10/13/16
to jenkin...@googlegroups.com
(replies inline)

On Thu, 13 Oct 2016, Robert Sandell wrote:

> I'm for it,
> But didn't we discuss a new "deprecation policy" in the beginning of the
> Jenkins 2 planning, or did I dream that?
> I'm mostly thinking of the rollout of this, many installations seems to
> have just dared to start thinking about upgrading to Jenkins 2, perhaps we
> shouldn't throw a Java upgrade in their face after just two LTS releases?
> Or maybe two is enough?


As far as the data is concerned, this is actually not true. With LTS moving to
a 2.x baseline, our most popular releases are now the 2.7.x LTSes, second place
is of course 1.651.x versions
(http://stats.jenkins.io/jenkins-stats/svg/201609-jenkins.svg).

It looks like slight majority of installations upgrade to the latest LTS within
3-5 months of its release, with the slight minority installing Jenkins and
likely never upgrading.


There's numbers in our usage data about which JREs are being used which needs
to get incorporated into stats.jenkins.io to help inform this discussion.



Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
signature.asc

Daniel Beck

unread,
Oct 13, 2016, 11:58:27 AM10/13/16
to jenkin...@googlegroups.com

> On 13.10.2016, at 17:53, R. Tyler Croy <ty...@monkeypox.org> wrote:
>
> There's numbers in our usage data about which JREs are being used which needs
> to get incorporated into stats.jenkins.io to help inform this discussion.

Re-run what you did for https://jenkins.io/blog/2015/11/03/what-jvm-versions-are-running-jenkins/ for the last ~3 months as a starting point?

Manfred Moser

unread,
Oct 13, 2016, 12:13:52 PM10/13/16
to Jenkins Developers
We recently did an upgrade to the latest 1.651.3 (latest 1.6 version) and had performance issues. When we switched to run it on Java 8 instead of Java 7 they all went away. We also had some plugin related problems.

I am mentioning this because this shows that all developers are using 1.8 and most testing is done 1.8 most likely as well. So from that background any users should be running Jenkins 1.8 already. We might as well make it official and drop 1.7 support. So

+1 

Manfred

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

Jesse Glick

unread,
Oct 13, 2016, 2:12:49 PM10/13/16
to Jenkins Dev
On Thu, Oct 13, 2016 at 12:13 PM, Manfred Moser <mos...@gmail.com> wrote:
> all developers are using 1.8
> and most testing is done 1.8 most likely as well. So from that background
> any users should be running Jenkins 1.8 already. We might as well make it
> official and drop 1.7 support.

Agreed. +1

Arnaud Héritier

unread,
Oct 13, 2016, 2:36:18 PM10/13/16
to jenkin...@googlegroups.com
Bye bye maven <evil> jobs that require java < 8 !!!
I just don't like to have such change in a minor release. 
Otherwise +1
--
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.

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


--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Daniel Beck

unread,
Oct 13, 2016, 4:03:00 PM10/13/16
to jenkin...@googlegroups.com

> On 13.10.2016, at 20:36, Arnaud Héritier <aher...@gmail.com> wrote:
>
> I just don't like to have such change in a minor release.

We already did it in 1.612.

The evil job type is a good point. Could Stephen or someone else who knows what they're talking about document how to circumvent this limitation with toolchains or something?

Stephen Connolly

unread,
Oct 13, 2016, 4:08:28 PM10/13/16
to jenkin...@googlegroups.com
Just dont use the evil one

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

Arnaud Héritier

unread,
Oct 13, 2016, 4:19:36 PM10/13/16
to jenkin...@googlegroups.com
On Thu, Oct 13, 2016 at 10:02 PM, Daniel Beck <m...@beckweb.net> wrote:

> On 13.10.2016, at 20:36, Arnaud Héritier <aher...@gmail.com> wrote:
>
> I just don't like to have such change in a minor release.

We already did it in 1.612.

Yes and in 1.520 for Java 6. I tried to explain/document it on the plugin page : https://wiki.jenkins-ci.org/display/JENKINS/Maven+Project+Plugin
 

The evil job type is a good point. Could Stephen or someone else who knows what they're talking about document how to circumvent this limitation with toolchains or something?


I wrote it. I wanted to push it on OSS side but I don't know where :( The problem is that there is no obvious place to do this.
On the wiki page of the plugin ?

 

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

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

Arnaud Héritier

unread,
Oct 13, 2016, 4:22:01 PM10/13/16
to jenkin...@googlegroups.com
On Thu, Oct 13, 2016 at 10:08 PM, Stephen Connolly <stephen.al...@gmail.com> wrote:
Just dont use the evil one

As soon as we'll provide a triggering mechanism like the evil job provides for SNAPSHOTs dependencies across projects it will be easy

 

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

Baptiste Mathus

unread,
Oct 13, 2016, 4:22:40 PM10/13/16
to Jenkins Developers
2016-10-13 22:19 GMT+02:00 Arnaud Héritier <aher...@gmail.com>:


On Thu, Oct 13, 2016 at 10:02 PM, Daniel Beck <m...@beckweb.net> wrote:

> On 13.10.2016, at 20:36, Arnaud Héritier <aher...@gmail.com> wrote:
>
> I just don't like to have such change in a minor release.

We already did it in 1.612.

Yes and in 1.520 for Java 6. I tried to explain/document it on the plugin page : https://wiki.jenkins-ci.org/display/JENKINS/Maven+Project+Plugin
 

The evil job type is a good point. Could Stephen or someone else who knows what they're talking about document how to circumvent this limitation with toolchains or something?


I wrote it. I wanted to push it on OSS side but I don't know where :( The problem is that there is no obvious place to do this.
On the wiki page of the plugin ?


Yes, I think this is probably the most sensible place. 

Daniel Beck

unread,
Oct 13, 2016, 5:23:04 PM10/13/16
to jenkin...@googlegroups.com

> On 13.10.2016, at 22:22, Baptiste Mathus <m...@batmat.net> wrote:
>
>> On the wiki page of the plugin ?
>
>
> Yes, I think this is probably the most sensible place.

I agree. Can always be moved elsewhere if needed, but as it's plugin specific (and not even part of the default configuration of Jenkins anymore…), plugin wiki page makes sense.

nicolas de loof

unread,
Oct 14, 2016, 3:11:00 AM10/14/16
to jenkin...@googlegroups.com
My +1 for Java 8 (as I have been advocating for this for 2.0 already)

About system that don't have Java 8 in official repo (RHEL5, Debian Wheezy, Ubuntu 14.04 LTS). Oracle do provide official JDK builds as DEB/RPM, so I can't see this as a blocker. For sure there's IT department, one need to convince to install a runtime that isn't part of official system repository... but that's just organisational issue we can't fix.

About maven job type, I wonder we could add better support for toolchain so jenkins can aytomagically select/install adequate JDK on slave, create toolchain.xml, and maybe even inject maven-toolchains-plugin in the lifecycle (is this possible ?). Maybe too much black magic ? Any improvement here would help getting a smooth transition.

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

Daniel Beck

unread,
Oct 14, 2016, 4:11:27 AM10/14/16
to Jenkins Developers

> On 14.10.2016, at 09:10, nicolas de loof <nicolas...@gmail.com> wrote:
>
> About system that don't have Java 8 in official repo (RHEL5, Debian Wheezy, Ubuntu 14.04 LTS).

Are you saying that RHEL 6 + 7, Debian Jessie, and Ubuntu 16.04 all _do_ have JRE 8 in their repos?

What about the other distros that have Jenkins packages? openSUSE, Gentoo, and the BSDs?

Any problems we anticipate for bundling JRE 8 with the Windows installer? (FWIW this could be done early, no need to wait for the runtime requirement…)

Sverre Moe

unread,
Oct 14, 2016, 4:56:09 AM10/14/16
to Jenkins Developers, m...@beckweb.net
Its a good move

SUSE distributions which has OpenJDK 8:
SLES 12 SP1
OpenSUSE 13.2
OpenSUSE Leap 42.1

Kanstantsin Shautsou

unread,
Oct 14, 2016, 7:20:31 AM10/14/16
to Jenkins Developers, m...@batmat.net
Jenkins still has guice-beta that randomly fails under java8.

nicolas de loof

unread,
Oct 14, 2016, 8:10:22 AM10/14/16
to jenkin...@googlegroups.com
Yes indeed, 
"OpenJDK 8 is included with RHEL 6.6 (and higher) and RHEL 7.1 (and higher), and it is fully supported." https://access.redhat.com/solutions/795263
java-package is available on jessie contrib, but java 8 is only available on wheezy in backports repo
Ubuntu : OpenJDK 8 is still not available in an official backport for 14.04. It is, however, available in 14.10 and forwards.
OpenSuse : can't tell, http://software.opensuse.org/package/java-1_8_0-openjdk is down for maintenance
Gentoo : not a distro I know well, but AFAIC there's no such thing as a LTS, so just use oracle-jdk-bin package
FreeBSD : not sure how those handle packages vs system releases. http://www.freshports.org/java/openjdk8 doesn't give info on system version it applies to
OpenBSD : ?

+1 for using Java 8 for windows installer package

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

nicolas de loof

unread,
Oct 14, 2016, 8:11:35 AM10/14/16
to jenkin...@googlegroups.com, m...@batmat.net
is there a jira issue to track this ?
I've been running jenkins on Java 8 without issue so far, so wonder about this runtime issue.

2016-10-14 13:20 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:
Jenkins still has guice-beta that randomly fails under java8.

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

Björn Pedersen

unread,
Oct 14, 2016, 8:21:38 AM10/14/16
to Jenkins Developers

FreeBSD : not sure how those handle packages vs system releases. http://www.freshports.org/java/openjdk8 doesn't give info on system version it applies to
It's available at least in FreeBSD9.1  (which is already quite old)
 

Samuel Van Oort

unread,
Oct 14, 2016, 10:41:20 AM10/14/16
to Jenkins Developers
I will jump for joy when everything is on Java 8.  Functional features or death!  Being able to consume the powerful libraries that are now Java 8-only (replacing Guava caches with Caffeine, for example, for a ~3x speed boost on all caching). 

Also @daniel-beck, this is another argument behind getting the current JVM stats (which I wanted for assessing default GC settings)

Jesse Glick

unread,
Oct 14, 2016, 4:49:20 PM10/14/16
to Jenkins Dev
On Fri, Oct 14, 2016 at 3:10 AM, nicolas de loof
<nicolas...@gmail.com> wrote:
> About maven job type, I wonder we could add better support for toolchain so
> jenkins can aytomagically select/install adequate JDK on slave, create
> toolchain.xml, and maybe even inject maven-toolchains-plugin in the
> lifecycle (is this possible ?). Maybe too much black magic ?

It already sets mojo properties to use the selected JDK.

Kanstantsin Shautsou

unread,
Oct 15, 2016, 11:37:57 AM10/15/16
to Jenkins Developers
I have no stacktrace and test case as we replaced guice to released version in our custom build. Will do of course when get again, but PR in core is blocked only by maven-plugin release.

Arnaud Héritier

unread,
Oct 15, 2016, 1:11:50 PM10/15/16
to jenkin...@googlegroups.com
I was supposed to work on it yesterday but I had a problem at home and I had to stop to work early. There are 2 PRs I would like to finalize before the release. I hope to do it tomorrow evening or at the later on Monday. I don't know if Olivier had some others todo ?


Le samedi 15 octobre 2016, Kanstantsin Shautsou <kanstan...@gmail.com> a écrit :
I have no stacktrace and test case as we replaced guice to released version in our custom build. Will do of course when get again, but PR in core is blocked only by maven-plugin release.

--
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/d71732a5-c118-446d-a1d1-01438ce3e3bd%40googlegroups.com.

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

Arnaud Héritier

unread,
Oct 15, 2016, 1:21:28 PM10/15/16
to jenkin...@googlegroups.com
FYI PR#66 I would like to apply Olivier's comment before applying it and PR#66 daniel's comment. 

Kanstantsin Shautsou

unread,
Oct 15, 2016, 1:57:49 PM10/15/16
to jenkin...@googlegroups.com
ROR

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/fo5nKLhZK5U/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/CAFNCU-8XUYxeQ-fardYEBoEy1zPOxWn%2B2HYhPbH4XMYqqxjQ3w%40mail.gmail.com.

Oleg Nenashev

unread,
Oct 18, 2016, 5:42:49 PM10/18/16
to Jenkins Developers
Weak -1 regarding JDK8, but the opinion is not that strong.
I'm pretty sure that now it will be a pretty big problem for low-end platfroms like Embedded Systems with hand-made OpenJDK builds.

We should rather consider investing into Java 9 Early Access IMHO. People will likely start submitting issues soon, and we may have serious issues with upgrade of our old lib forks

BR, Oleg

суббота, 15 октября 2016 г., 19:57:49 UTC+2 пользователь Kanstantsin Shautsou написал:
ROR

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

nicolas de loof

unread,
Oct 19, 2016, 1:47:36 AM10/19/16
to jenkin...@googlegroups.com
@Oleg I totally agree we need to investigate java 9 support  - for your information, jenkins doesn't boot on java9+jigsaw, see https://github.com/x-stream/xstream/issues/74



nicolas de loof

unread,
Oct 19, 2016, 1:56:20 AM10/19/16
to jenkin...@googlegroups.com
Have just read Java 9 is postponed to 2017/07/27, give us some extra time to look into this

Kanstantsin Shautsou

unread,
Oct 19, 2016, 10:29:41 AM10/19/16
to Jenkins Developers

Baptiste Mathus

unread,
Oct 27, 2016, 9:52:54 AM10/27/16
to Jenkins Developers
Quick heads-up: we should have more data soon about the share of Java 8 & Java 7: https://github.com/jenkins-infra/infra-statistics/pull/21 

In the meantime, any additional review/opinion on that change, and/or the data you think would be interesting to extract from there is welcome.

2016-10-19 16:29 GMT+02:00 Kanstantsin Shautsou <kanstan...@gmail.com>:

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

Baptiste Mathus

unread,
Oct 28, 2016, 9:17:09 AM10/28/16
to Jenkins Developers
Hello Folks,

PR got merged, so now we have some data. I've twiddled with the raw json to make it more human readable, see that google spreadsheet.

TL;DR:
  • On the whole Jenkins instances (i.e. all Jenkins versions included), Java 8 is used for 52% of them, growing.
  • If we look only at Jenkins 2.x, then Java 8 is used for 67% of the instances, growing.  
Jenkins 2.x stats:
Images intégrées 1

Entire stats, taking every single instance in the world (some Jenkins 1.3xx included :-)):

Images intégrées 2



​.

Martina

unread,
Oct 28, 2016, 7:40:30 PM10/28/16
to Jenkins Developers, m...@batmat.net
btw. game-of-life that we all dearly love for demos only runs with jdk7, not jdk 8, at least the master branch does. https://github.com/CloudBees-community/game-of-life
Not sure how/where to report it, so I'm guessing that the right powers-to-be see this one.

- Martina

nicolas de loof

unread,
Oct 29, 2016, 3:21:58 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net

Jenkins can require Java 8, but needs to support building arbitrary Java project, even jdk 1.0 ;)


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

Arnaud Héritier

unread,
Oct 29, 2016, 3:48:20 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net
If you don't use the maven evil job type
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzndQmE3qpQ-jt2R%2BnXPFuqoogrq9fyw10b3uES4%3D7t%2BJA%40mail.gmail.com.

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

nicolas de loof

unread,
Oct 29, 2016, 4:11:11 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net

... or rely on tool chain, that has been designed to cover this exact issue.
Didn't we had this debate few days ago ?


Arnaud Héritier

unread,
Oct 29, 2016, 4:24:07 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net
Are you proposing to write a real/good toolchain integration for Jenkins ? That will allow to generate / configure the config file based on what Jenkins deploys ? Ok with docker it is simpler to create an image with several JDKs and the configuration file hardcoded (in that case the challenge is to choose the docker plugin to use ..)
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmRZ%2BT9B%2BVz46K-v8OgkwtC%2B7AUjnCoNR1DHg9ufrZFbg%40mail.gmail.com.

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

nicolas de loof

unread,
Oct 29, 2016, 6:26:14 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net
I indeed think we will have to support the evil maven job type for one more decade, so need to make it flexible enough so migrating jenkins codebase to a newer JDK is not blocked y this beast. As maven do support toolchain, I just would like maven job do fully rely on it without any extra configuration so end user don't have to worry about this terrible runtime dependency.

Arnaud Héritier

unread,
Oct 29, 2016, 6:34:01 AM10/29/16
to jenkin...@googlegroups.com, m...@batmat.net
The problem is that when a user have a large number of maven jobs running on old JDKs, these are often legacy projects where the maintenance cost must be 0. The problem is that using toolchains requires to update you maven project and thus they'll probably won't do it :(
Another solution may to work on a converter to freestyle or pipeline jobs .... Maybe they could prefer to loose some features if they gain in maintainability...



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

Baptiste Mathus

unread,
Oct 29, 2016, 8:11:47 AM10/29/16
to Arnaud Héritier, jenkin...@googlegroups.com

Yes, but aren't we then back to the point, Arnaud: anyway, places/companies where cost must be 0 are not going to upgrade to new Jenkins version anyway?

And when they're forced to upgrade at some point, in the meantime they're likely to have also been forced to upgrade the Jdk from 7 to 8 on those projects? Should we block the OSS project because, say, <30% of users won't upgrade? If so, then why not, but how long? Since that category of users basically only upgrades when forced to anyway?

IMO, we could just define some future arbitrary date to give time to everybody if we agree this is time. For example, announce on the blog and everywhere we can that the first weekly version of 2017 (or some later date) will be on java 8 min. This would give time for users to upgrade, and possibly for the plugin to be improved wrt the multi-jdk support, by OSS maintainers and/or companies who want to help theirs customers with this upgrade.

WDYT?


Arnaud Héritier

unread,
Oct 29, 2016, 8:52:39 AM10/29/16
to Baptiste Mathus, jenkin...@googlegroups.com
From my POV the problem is that we don't know if we are talking about 5% or 50% :(

For sure, with any solution it will be painful for them. The risk being is that a big breakage for them gives the opportunity to move to something else. 

About communication/anticipation it is a mandatory pre-requisite but I would really prefer that we call it jenkins 3.0. To make obvious the breaking change. 

For me changing the java runtime prerequisite in a minor version is a really strange strategy...

Baptiste Mathus

unread,
Oct 29, 2016, 9:27:03 AM10/29/16
to Jenkins Developers
2016-10-29 14:52 GMT+02:00 Arnaud Héritier <aher...@gmail.com>:
From my POV the problem is that we don't know if we are talking about 5% or 50% :(


  • Java 8 as runtime represents 52% of the 133505 instances out there (yes, it's ignoring the opted-out ones)
  • Maven-plugin is installed 118711 times (yes, ignoring on purpose the fact it was auto-installed up to 2.x)
  • So, at most it's 46% of the users base who might be impacted here, if they were to upgrade in the very short term (that is: while also still using an EoLed JDK7 durably).
Now, looking at the trend of the number of installs of that plugin, my guts feeling is that is less than that. And if you add that to the trend of Java 7 JVM users (see link above), then it is most probably going down even quicker.

An example I have in mind is my previous company, pretty sure they didn't upgrade to Jenkins 2.x yet, so they still contribute to that stats, but we migrated off that plugins years ago after so many headaches and hours spent to debug different behaviours between Maven CLI and using it in Jenkins.

Correlating with http://stats.jenkins.io/plugin-installation-trend/jenkins-version-per-plugin-version.json I think we would have even more data, but seems like that data is wrong. 
Gonna find the one who contributed that and hit him (I know him pretty well).

Stephen Connolly

unread,
Oct 29, 2016, 9:37:08 AM10/29/16
to jenkin...@googlegroups.com
I think we should say "the first LTS of 2017 will require Java 8. End of conversation"

That will mean that weekly releases should switch to Java 8 by mid-end November.

2017 it's a new year, it's a new Java version.

We could look to solve some of the evil job type issues by *forking* remoting into the evil plugin and using animal-sniffer to keep plugins "pure"
--
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.

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


--
Sent from my phone

Arnaud Héritier

unread,
Oct 29, 2016, 10:01:41 AM10/29/16
to jenkin...@googlegroups.com
Let's forget the maven job. Our statistics about its usage are useless as it was installed by default and we may hope that its usage is decreasing...

It remains that upgrading the java version of master is one thing. But you also need to upgrade the java version used by agents which aren't supporting an automated deployment (hello JNLP slaves on windows ...).

My problem is (and was for years when I administrated many instances) the readibilty of the changelog/roadmap to understand when an important change was done. I have no problem to release a java 8 version tomorrow in a Jenkins 3.0 release. But in a 2.38 or 2.51.1 (fictifs versions) will be always really strange for me. A minor release shouldn't enforce you to change your infrastructure deployment (and possibly break many jobs but it's a different story)

That's just my POV. 

Cheers. 


Le samedi 29 octobre 2016, Baptiste Mathus <m...@batmat.net> a écrit :
--
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.

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

Hickel, Kelly

unread,
Oct 29, 2016, 10:22:12 AM10/29/16
to jenkin...@googlegroups.com

Any chance of getting a the manage nodes screen changed to include the java version for that agent, in advance of forcing Java 8 in the weekly builds?

 

That would at least make it simpler for folks like myself to know the scale of the upcoming impact.

 

Thanks,

Kelly Hickel

 

From: jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] On Behalf Of Stephen Connolly
Sent: Saturday, October 29, 2016 8:37 AM
To: jenkin...@googlegroups.com
Subject: Re: [DISCUSS] Time for Jenkins to require Java 8 to run

 

I think we should say "the first LTS of 2017 will require Java 8. End of conversation"

 

That will mean that weekly releases should switch to Java 8 by mid-end November.

 

2017 it's a new year, it's a new Java version.

 

We could look to solve some of the evil job type issues by *forking* remoting into the evil plugin and using animal-sniffer to keep plugins "pure"

On Saturday 29 October 2016, Baptiste Mathus <m...@batmat.net> wrote:

 

2016-10-29 14:52 GMT+02:00 Arnaud Héritier <aher...@gmail.com>:

From my POV the problem is that we don't know if we are talking about 5% or 50% :(

 

 

  • Java 8 as runtime represents 52% of the 133505 instances out there (yes, it's ignoring the opted-out ones)
  • Maven-plugin is installed 118711 times (yes, ignoring on purpose the fact it was auto-installed up to 2.x)
  • So, at most it's 46% of the users base who might be impacted here, if they were to upgrade in the very short term (that is: while also still using an EoLed JDK7 durably).

Now, looking at the trend of the number of installs of that plugin, my guts feeling is that is less than that. And if you add that to the trend of Java 7 JVM users (see link above), then it is most probably going down even quicker.

 

An example I have in mind is my previous company, pretty sure they didn't upgrade to Jenkins 2.x yet, so they still contribute to that stats, but we migrated off that plugins years ago after so many headaches and hours spent to debug different behaviours between Maven CLI and using it in Jenkins.

 

Correlating with http://stats.jenkins.io/plugin-installation-trend/jenkins-version-per-plugin-version.json I think we would have even more data, but seems like that data is wrong. 

Gonna find the one who contributed that and hit him (I know him pretty well).

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



--
Sent from my phone

--

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/CA%2BnPnMyrp%2BYTyij2w8dqnHpaE%2B77MS10AWfv3pyBpYeE5Egotg%40mail.gmail.com.

Arnaud Héritier

unread,
Oct 29, 2016, 3:58:53 PM10/29/16
to jenkin...@googlegroups.com
There is an additional plugin which displays the version of the agent used (which is critical to manage too)
I would have loved to have this in info by default and I agree that the java version could make sense too

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



--
Sent from my phone

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

--
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/97e7456e1c854a828b7a2a2d1a94d79a%40hou-exmbprd-01.adprod.bmc.com.

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



--

Martina

unread,
Oct 29, 2016, 4:00:58 PM10/29/16
to Jenkins Developers, m...@batmat.net
My concern was that at some point jdk 7 will not be welcome in certain corporate environments. While consultants can do what they please on their boxes, folks having to comply with corporate rules won't be able to use game-of-life for training, demo, learning etc.
It would be a good deed to get it fixed.

-Martina


On Saturday, October 29, 2016 at 1:21:58 AM UTC-6, nicolas de loof wrote:

Jenkins can require Java 8, but needs to support building arbitrary Java project, even jdk 1.0 ;)

Le 29 oct. 2016 1:40 AM, "Martina" <martina...@gmail.com> a écrit :
btw. game-of-life that we all dearly love for demos only runs with jdk7, not jdk 8, at least the master branch does. https://github.com/CloudBees-community/game-of-life
Not sure how/where to report it, so I'm guessing that the right powers-to-be see this one.

- Martina

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

Baptiste Mathus

unread,
Oct 29, 2016, 4:14:31 PM10/29/16
to Jenkins Developers

Hey,
Please file an issue in the repo, or a PR. I was able to build the repo without an issue with Java 8, so this will need clarification...

Thanks


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/cfd27c6d-aa5b-4f05-a834-740a30fefe81%40googlegroups.com.

Martina Riedel

unread,
Oct 29, 2016, 4:32:56 PM10/29/16
to jenkin...@googlegroups.com
It builds but it doesn't run.
From the README: go to the gameoflife-web directory and run mvn jetty:run. The application will be running on http://localhost:9090.

I don't see the Issues tab on https://github.com/CloudBees-community/game-of-life. And no, I don't have a fix, so no PR. I just installed jdk 7.
I can reproduce if needed.

Martina
   Don't Postpone Joy - Have Fun


R. Tyler Croy

unread,
Oct 29, 2016, 4:46:09 PM10/29/16
to jenkin...@googlegroups.com
(replies inline)

On Sat, 29 Oct 2016, Martina Riedel wrote:

> It builds but it doesn't run.
> From the README: go to the gameoflife-web directory and run mvn jetty:run.
> The application will be running on http://localhost:9090.
>
> I don't see the Issues tab on
> https://github.com/CloudBees-community/game-of-life. And no, I don't have a
> fix, so no PR. I just installed jdk 7.
> I can reproduce if needed.


This is off-topic for this thread, and not concerning a Jenkins project
repository so I kindly ask that this discussion continue elsewhere.



- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
signature.asc

Christopher Orr

unread,
Oct 30, 2016, 8:08:00 PM10/30/16
to jenkin...@googlegroups.com
On 29/10/16 16:01, Arnaud Héritier wrote:
> Let's forget the maven job. Our statistics about its usage are useless
> as it was installed by default and we may hope that its usage is
> decreasing...

AFAIK, basic usage of job types has always been available in the
statistics. From the September CSV:

Job type Count %
IvyModuleSet 6311 0.1
WorkflowMultiBranchProject 17229 0.2
InheritanceProject 20407 0.2
WorkflowJob 139976 1.5
MatrixProject 306274 3.2
MavenModuleSet 1236525 13.1
FreeStyleProject 7725160 81.7


> It remains that upgrading the java version of master is one thing.
> But you also need to upgrade the java version used by agents which
> aren't supporting an automated deployment (hello JNLP slaves on windows
> ...).
>
> My problem is (and was for years when I administrated many
> instances) the readibilty of the changelog/roadmap to understand when an
> important change was done. I have no problem to release a java 8 version
> tomorrow in a Jenkins 3.0 release. But in a 2.38 or 2.51.1 (fictifs
> versions) will be always really strange for me. A minor release
> shouldn't enforce you to change your infrastructure deployment (and
> possibly break many jobs but it's a different story)

Jenkins has never used some sort of semantic versioning, so I don't
think it would make a difference. In any case, things seemed to go
fairly smoothly when Jenkins started to require Java 7, and the changes
were clearly highlighted in the changelog, communicated with blog posts,
and on Twitter.


> Le samedi 29 octobre 2016, Baptiste Mathus <m...@batmat.net
> <mailto:m...@batmat.net>> a écrit :
>
>
> 2016-10-29 14:52 GMT+02:00 Arnaud Héritier <aher...@gmail.com
> <javascript:_e(%7B%7D,'cvml','aher...@gmail.com');>>:
>
> From my POV the problem is that we don't know if we are talking
> about 5% or 50% :(
>
>
> Well, since yesterday, we do know some things
> <https://docs.google.com/spreadsheets/d/1_gsorbySktXNjMywDFZE0_eTm_r2zfPKdmq7AqWO2uQ/edit#gid=1770972416>.
>
> * Java 8 as runtime represents 52% of the 133505 instances out
> there (yes, it's ignoring the opted-out ones)
> * Maven-plugin is installed 118711 times (yes, ignoring on purpose
> the fact it was auto-installed up to 2.x)
> * So, *at most* it's 46% of the users base who *might *be impacted

Jesse Glick

unread,
Oct 31, 2016, 9:40:05 AM10/31/16
to Jenkins Dev
On Sat, Oct 29, 2016 at 6:33 AM, Arnaud Héritier <aher...@gmail.com> wrote:
> The problem is that when a user have a large number of maven jobs running on
> old JDKs, these are often legacy projects where the maintenance cost must be
> 0. The problem is that using toolchains requires to update you maven project

I feel like I am repeating myself, but: if you run a Maven project
configured to use an older JDK than what Jenkins (master + agent)
supports, the plugin *already* switches your build to use external
tools from that JDK (while Maven itself runs in the same JRE as the
node). This happens using properties defined for common mojos; there
is no need to switch to toolchains or edit your POM. Now this is not
going to handle exotic plugins or POMs with weird configuration, but
it should handle the vanilla cases. This has been true for a long
time, since we dropped JDK 5 support IIRC.

Arnaud Héritier

unread,
Oct 31, 2016, 10:22:56 AM10/31/16
to jenkin...@googlegroups.com
Yes we are agree but I really dislike this feature which is trying magically to do a fix.
In the latest version of the plugin I tried to make visible the warning when it occurs.
Building with with a JDK 8 and target/sources configured in java 7 is far from beeing perfect.
But like I said I'm really less annoyed by the maven job breakage than by the deployment pre-requisite change which occurs in a minor release.
But like Christopher said, it was always like this and we aren't following semver at all.
It's up to the users to correctly read in details our release notes to evaluate the risk in each upgrade


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

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

Daniel Beck

unread,
Oct 31, 2016, 10:41:45 AM10/31/16
to Jenkins Developers

> On 31.10.2016, at 15:22, Arnaud Héritier <aher...@gmail.com> wrote:
>
> It's up to the users to correctly read in details our release notes to evaluate the risk in each upgrade

For LTS at least we've started doing upgrade guides, emphasizing possibly breaking changes.

Arnaud Héritier

unread,
Oct 31, 2016, 10:58:11 AM10/31/16
to jenkin...@googlegroups.com
I wasn't aware of this : https://jenkins.io/doc/upgrade-guide/
a big +++++1

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

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

Jesse Glick

unread,
Oct 31, 2016, 2:51:36 PM10/31/16
to Jenkins Dev
On Mon, Oct 31, 2016 at 10:22 AM, Arnaud Héritier <aher...@gmail.com> wrote:
> I really dislike this feature which is trying magically
> to do a fix.

I dislike it too, it is just a last resort for people who are too lazy
to fix their project definitions to use Animal Sniffer, toolchains,
etc. and thus be independent of the JRE used to run Maven itself. (Or
of course if you do not rely on other `maven-plugin` features you can
switch to a freestyle project with a Maven build step, or even
Pipeline with `docker.image('maven:whatever').inside {…}`).

Baptiste Mathus

unread,
Nov 27, 2016, 2:43:29 PM11/27/16
to Jenkins Developers
FWIW, after the advice of Tyler, I created a blog entry on jenkins.io summarizing the numbers I posted previously: https://jenkins.io/blog/2016/11/22/what-jvm-versions-are-running-jenkins-the-return/
Seems like there's somehow an agreement, there's potentially some issues with the maven-plugin, but even there there're apparently workarounds or solutions.

So, how do we move forward here? 

Here's a tentative proposal.

Given:
  • 2.19.4 is going out on very soon supposedly
  • As the next LTS/2.32 is already chosen, I guess the 2.32.1 should be out early January (or late December?)
  • Which means, the next baseline choice should happen around March or April.
Hence, we could decide to switch to JDK8 baseline for the first weekly of 2017? Or do you think it's a too short notice?

This would give us ~12 weeks to check how that works with weeklies before the first JDK8 LTS is out.

WDYT?
Oliver, as the LTS King, what do you think?

Caveat/Warning: this might mean that especially for backportable bugfixes, for 12-16 weeks, we might want to take extra care about not using JDK8 features too much. 

BTW, how was all that handled for JDK6 => JDK7 back then?

Oleg Nenashev

unread,
Nov 27, 2016, 3:11:25 PM11/27/16
to JenkinsCI Developers
  • As the next LTS/2.32 is already chosen, I guess the 2.32.1 should be out early January (or late December?)
Late December
  • Which means, the next baseline choice should happen around March or April.
It will be late February

Hence, we could decide to switch to JDK8 baseline for the first weekly of 2017? Or do you think it's a too short notice?

IMHO it's too short. I'd rather make announcement and wait for another 3 months till the new LTS line. I'm still not a big fan about dropping Java 7, but .

--
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/fo5nKLhZK5U/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/CANWgJS6EaOKgFQNMJ553szWXT%2BYPiBj-UD36zLEbCvT8BOGCgA%40mail.gmail.com.

ogondza

unread,
Dec 1, 2016, 3:08:48 AM12/1/16
to Jenkins Developers, m...@batmat.net
I am undecided on the subject. There clearly always are reasons to use newer/better version but is JDK 7 support really blocking us somewhere? Bugs we cannot fix / need to awkwardly compensate, features we can not deliver on Java 7?

I felt much stronger against dropping Java 6 as we identified several architecture/OS combinations with no Java 7+ vendor making the platforms (RHEL4, itanium architecture, Solaris 9 (IIRC)) not usable as Jenkins nodes. (Yes, you can run agent on older Java version but it causes subtle problems.) However, oracle does not seem to drop any of the platforms (at least those we care for) between 7 and 8.

What we can do right now, to make this a bit less troublesome to users and easier to digest for community, is creating a general time plan for dropping support of JDKs (or other things) we would follow in specific cases. Something like:

- Month 0: Announce the intention publicly, with this plan attached.
- Month 3: Drop support for Jenkins weekly. Declare what LTS will be the last one to support the think we are dropping. Since we gave people time to get prepared, we do not have to try hard to prolong the support in LTS branch. IOW, I see no reason to do whole new LTS line after the support was dropped for weeklies.
- Month 3-5: LTS.1 with support dropped is released.
- Month 12?: In case of Java, encourage the use from plugins / use it as default. Extending the support in plugins allow people to consume plugin updates/fixes after upstream has dropped support without upgrading Java. This is especially subtle as IIRC plugin manager offers plugin updates (perhaps even core ones) that require newer Java version than the one installed on master, and there is no guarantee plugin that needs Java 8 require core with same requirement.

--
oliver

Oleg Nenashev

unread,
Dec 1, 2016, 3:21:31 AM12/1/16
to JenkinsCI Developers, Baptiste Mathus
The plan looks good to me.
I'm also thinking about dropping the .NET 2.0 support in Windows installer and windows-slave-installer. If we drop Java 7, I would like to join the party and to announce the .NET2 and 3.5 deprecation and selection of .NET4 as a baseline.

.NET 4 is 5 years old && available on Operating systems including the latest Windows XP service pack. The situation with Embedded Windows versions is a bit worse, so we may still impact a particular subset of users.

If there is no strong -1s, I will start a standalone discussion of it.

P.S: Maybe we also want to discontinue support of Windows 32 bit systems and other such stuff. But it's very debatable

--
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/fo5nKLhZK5U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

Jesse Glick

unread,
Dec 1, 2016, 3:47:37 PM12/1/16
to Jenkins Dev
On Thu, Dec 1, 2016 at 3:08 AM, ogondza <ogo...@gmail.com> wrote:
> is JDK 7 support really blocking us somewhere? Bugs
> we cannot fix / need to awkwardly compensate, features we can not deliver on
> Java 7?

Of course not. It just slows down developers trying to work on new
things in the name of supporting an old system most users are not
running (or need not run) and which we do not really test on anyway.

> you can run agent on older Java version but it causes subtle
> problems.

It will not work at all—you will get `ClassFormatError`s. If you
really need to build some projects on obsolete operating systems, you
can run the Jenkins agent on a normal computer, then SSH into an old
box or use VirtualBox or Docker or whatever to do the actual build
steps.

> plugin manager offers plugin updates
> (perhaps even core ones) that require newer Java version than the one
> installed on master

Yes there is a long-filed RFE to include the minimum JRE requirement
in plugin metadata. In the meantime,

> there is no guarantee plugin that needs Java 8
> require core with same requirement.

plugin authors are strongly advised to build against the same Java
Platform version as that used as a minimum by their minimum core
dependency. Thus, for example, you may delete

<java.level>6</java.level>

in your POM (and so go to the default of 7) when you update your
baseline to 1.625.x or later.

Baptiste Mathus

unread,
Dec 2, 2016, 5:44:14 PM12/2/16
to ogondza, Jenkins Developers
thanks Oliver

2016-12-01 9:08 GMT+01:00 ogondza <ogo...@gmail.com>:

[...]
 
- Month 0: Announce the intention publicly, with this plan attached.
- Month 3: Drop support for Jenkins weekly. Declare what LTS will be the last one to support the think we are dropping. Since we gave people time to get prepared, we do not have to try hard to prolong the support in LTS branch. IOW, I see no reason to do whole new LTS line after the support was dropped for weeklies.
- Month 3-5: LTS.1 with support dropped is released.

That plan looks sensible to me.

I guess we might want to take that decision to the next gov meeting to make it acknowledged and official to get this plan going, isn't it? 
 
- Month 12?: In case of Java, encourage the use from plugins / use it as default. Extending the support in plugins allow people to consume plugin updates/fixes after upstream has dropped support without upgrading Java. This is especially subtle as IIRC plugin manager offers plugin updates (perhaps even core ones) that require newer Java version than the one installed on master, and there is no guarantee plugin that needs Java 8 require core with same requirement.

IMO, this is definitely something we want to improve (as says Jesse with embedding that in plugins metadata somehow), but IMO can be a disconnected discussion.


--
oliver


James Nord

unread,
Dec 7, 2016, 7:01:15 AM12/7/16
to Jenkins Developers, ogo...@gmail.com, m...@batmat.net
I am -1000 on this.

The code does not pass tests on windows.  Using java8 you force me to use a Virtual machine which sucks.

Using Windows subsystem for Linux gets you ubuntu 14.04 which does not have native support for JDK8.

Basically please don't do this until you have a solution for Windows developers.

Jesse Glick

unread,
Dec 7, 2016, 9:23:33 AM12/7/16
to Jenkins Dev
On Wed, Dec 7, 2016 at 7:01 AM, James Nord <jn...@cloudbees.com> wrote:
> The code does not pass tests on windows. Using java8 you force me to use a
> Virtual machine

Can you be more specific about the problems you have? What tests do
not pass? On Java 8 only you mean? If there are mistakes in tests, we
should fix them ASAP. Even when (nominally) supporting Java 7 for
runtime, JDK 8 is the preferred build environment.

Baptiste Mathus

unread,
Dec 7, 2016, 12:47:24 PM12/7/16
to Jenkins Developers
I had added this subject to the gov meeting for tonight since there hasn't been strong pushback for 6 weeks.
But as I will most likely not be able to be present (in 13' now), I don't know if this should be kept or not in the agenda.

I think that the plan proposed by Oliver would still work though: I.e. start in ~3 months from now or so to upgrade the baseline for weeklies. This would probably give enough time to address the potential issues left for Windows developers. 

We will be able to just postpone the switch a bit more if needed. Still announcing the switch, because giving possibly more time for users to react/ack that is anyway not going to be useless.


--

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/CANfRfr37Q8tvwNUxet5b2oDrAHK4NaLsknqMxUQEXLRETyAsvg%40mail.gmail.com.

James Nord

unread,
Dec 7, 2016, 2:33:58 PM12/7/16
to Jenkins Developers

James Nord

unread,
Dec 7, 2016, 2:39:32 PM12/7/16
to Jenkins Developers
Damn sent to early...  The above is issues when my JDK is 1.8.  Using 1.7 on Windows I see the same failures.
which means I need to fallback to a Linuxy machine to run tests.   Using bash on Ubutnu on Windows I only have jdk7.  (more available downloading directly but given the nature of WSL it would be better to stick to what is in the official apt repos so that support is available)

Slide

unread,
Dec 7, 2016, 6:10:56 PM12/7/16
to Jenkins Developers
I took a small peek at this (I commented this on the issue you filed as well) and found that 8 of the 9 errors are probably due to symlink creation. By default only certain accounts can create symlinks on Windows. Jenkins warns about this and gives you the information on how to add your user account to the list of allowed symlink creators (or you can run your command line as Administrator). I didn't try the security change yet, I did try running PowerShell as Administrator and those 8 errors went away. The last one is a line ending issue in RunTest. The last assertion checks for a truncated count of bytes, on Windows since it uses \r\n for line endings will have 10 additional bytes, which is why the message is incorrect. I proposed a small patch (not the best way to do it I am sure) that allows that test to pass as well.

The last issue I get is an issue during the war build. It errors when trying to install node.exe.

--
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/9cacaa2c-3f6c-43c5-b584-4e63b4f760bc%40googlegroups.com.

Baptiste Mathus

unread,
Dec 18, 2016, 4:11:12 PM12/18/16
to Jenkins Developers, ogondza
@James, so can you please give us an update of the current state about this?

My understanding is the following below, can you confirm/complete?

2016-12-07 13:01 GMT+01:00 James Nord <jn...@cloudbees.com>:
I am -1000 on this.

The code does not pass tests on windows.  Using java8 you force me to use a Virtual machine which sucks.

So, IIUC, the tests are actually already failing with JDK7. So though I agree this is important to fix (and Alex provided an interested feedback about that, thanks Alex!), I guess this isn't a criterion for JDK7=>JDK8 upgrade, right?
 

Using Windows subsystem for Linux gets you ubuntu 14.04 which does not have native support for JDK8.

If the first reason is actually fixable, does it make that second one still actual? My understanding is no, because w/o Linux specific tests, you would be able to work without falling back to using the VM subsystem.

And even if so, IIRC, we found there was apparently a (currently) Beta program when one could get 16.04, hence JDK8, right? In that case, it should/could appear reasonable then because in the meantime of the actual baseline upgrade (D+3 Months for weeklies as per Oliver's proposal) that Beta could possibly have graduated to GA (if it hasn't already?).

IOW, do you still have any reason to want to block that baseline upgrade, or are you now fine with it?

Thanks

-- Baptiste

James Nord

unread,
Dec 19, 2016, 3:05:44 PM12/19/16
to Jenkins Developers, ogo...@gmail.com, m...@batmat.net


On Sunday, December 18, 2016 at 9:11:12 PM UTC, Baptiste Mathus wrote:
@James, so can you please give us an update of the current state about this?

My understanding is the following below, can you confirm/complete?

2016-12-07 13:01 GMT+01:00 James Nord <jn...@cloudbees.com>:
I am -1000 on this.

The code does not pass tests on windows.  Using java8 you force me to use a Virtual machine which sucks.

So, IIUC, the tests are actually already failing with JDK7.

On windows they fail with JDK7 or JDK8 - the issue is that you can not have a non virtual dev env on Windows 10 iff you move to require JDK8 as bash in ubuntu in windows does not support JDK8

 
So though I agree this is important to fix (and Alex provided an interested feedback about that, thanks Alex!), I guess this isn't a criterion for JDK7=>JDK8 upgrade, right?

Well that depends... 
Currently I can build on windows using bash on ubuntu on windows using JDK7.
And as such if you required JDK8 I would not be able to build (and have all the unit tests passing) 
 
 

Using Windows subsystem for Linux gets you ubuntu 14.04 which does not have native support for JDK8.

If the first reason is actually fixable, does it make that second one still actual? My understanding is no, because w/o Linux specific tests, you would be able to work without falling back to using the VM subsystem.

I don't follow...
 

And even if so, IIRC, we found there was apparently a (currently) Beta program when one could get 16.04, hence JDK8, right?

Right.....  Let me switch my primary OS over to use Windows insider program as well as Beta software I already have to use, what could possibly go wrong :-P

 
In that case, it should/could appear reasonable then because in the meantime of the actual baseline upgrade (D+3 Months for weeklies as per Oliver's proposal) that Beta could possibly have graduated to GA (if it hasn't already?).

Well in 3 months I hope the tests could be fixed and stay fixed instead :-)
(OT: I think the MS updates come in 6 month intervals so 3 months from now would be a little too quick)
 

IOW, do you still have any reason to want to block that baseline upgrade, or are you now fine with it?

What I'm saying is that by the time this call is made to switch there needs to be a native solution for building Jenkins on Windows (and Linux and OSX[1]).  The easiest approach I see would be to fix the unit tests /code  - which Alex already took a look at and should be possible.

So I am +1k on switching to JDK8 with the proviso that at the time the call is made to do that the code is building and passing tests correctly.

[1] not that there are any OSX agents on ci.jenkins.io - but normally OSx is closeish enough to Linux that you don't hit things like locking/network stack differences/line ends/spaces in dir names which cause tests/code to fail.



Baptiste Mathus

unread,
Dec 21, 2016, 9:42:12 AM12/21/16
to Jenkins Developers
OK, sounds like a plan. IIUC think we have an agreement.

> So I am +1k on switching to JDK8 with the proviso that at the time the call is made to do that the code is building and passing tests correctly.

So I propose we do three things:

1) Start the process proposed by Oliver, Day 0 will be when the blog entry is published
2) Fix the Windows failing tests (on adding the right assumptions depending on the cases)
2') Modify Jenkinsfile to build also the core on Windows -- I'm volunteering to drive that, and can commit to do it (or reconcile the possibly existing bits) before the end of January.

If we agree and publish the blog entry and announces on the users ML, then it would make the ~ 2.50 (2.37+12) the first weekly to be JDK8 baselined.
So as to Oliver's plan, there would be ~ 3 to 5 months from now for the first JDK8 LTS.

Any issue with this plan?

I won't be able to attend the gov meeting tonight again. But I'm hopeful that could be discussed w/o me like last time 
(yeah, contrary to my initial thoughts, finally bitten myself by the time shift of the gov meeting we did some weeks ago, a wee bit too early for me those days :-/).

-- Baptiste


--
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/cf7f0681-ab03-499b-9b04-31ff8f591d75%40googlegroups.com.

Slide

unread,
Dec 21, 2016, 9:43:43 AM12/21/16
to Jenkins Developers
I have a PR almost ready for Jenkinsfile to build on Windows and Linux.

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

--
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/CANWgJS4d5r_Jd9yg69GCFy3ORtMUSt5v5gAWhVQqK07hVhqu_g%40mail.gmail.com.

Baptiste Mathus

unread,
Dec 21, 2016, 11:24:36 AM12/21/16
to Jenkins Developers
Great, Alex \o/.

Tyler had played a bit the informer about it on you, but couldn't find this on the existing PRs and didn't ask you afterwards. ;-)
Then mostly fixing tests is left TBD IIUC.

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

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

--
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/CAPiUgVe8ZtDH0VKzHOppkg4GwD0_7hp76Ffdvk4WhjB6z-HrCQ%40mail.gmail.com.

Baptiste Mathus

unread,
Jan 3, 2017, 4:46:03 PM1/3/17
to Jenkins Developers
Follow-up: https://github.com/jenkinsci/jenkins/pull/2698 is the PR to add Windows build to the core. 

Thanks Alex! 

Review welcome to speed up the process and merge hopefully soon.

Baptiste Mathus

unread,
Jan 16, 2017, 3:26:29 AM1/16/17
to Jenkins Developers

Oleg Nenashev

unread,
Mar 10, 2017, 6:39:07 AM3/10/17
to Jenkins Developers, m...@batmat.net
Just a standalone topic.
Migration to Java 8 may likely break use-cases with Maven plugin when it uses Java 7 (and it WILL break it if we migrate remoting).
There is a valid question about it here

Even if all of us agree that Maven plugin should be used with case, do we want to somehow handle this use-case and retain the compatibility?

BR, Oleg


понедельник, 16 января 2017 г., 9:26:29 UTC+1 пользователь Baptiste Mathus написал:
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

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

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

Baptiste Mathus

unread,
Mar 29, 2017, 6:19:27 PM3/29/17
to Jenkins Developers
PR for Java 8 baseline bump is up at https://github.com/jenkinsci/jenkins/pull/2802

Reviews much welcome.

Thanks!
Reply all
Reply to author
Forward
0 new messages