Core Baseline Java8 -> Java11?

138 views
Skip to first unread message

Ullrich Hafner

unread,
Dec 3, 2020, 10:57:18 AM12/3/20
to Jenkins Developers
Are there already plans to move the Java baseline from Java 8 to Java 11 in the near future in Jenkins core?

Mark Waite

unread,
Dec 3, 2020, 12:40:01 PM12/3/20
to jenkinsci-dev
There are not.  Considering the relatively low adoption rate of Java 11, I'd personally resist a move to make Java 11 the baseline for quite a while unless there were some way to preserve and assure that Java 8 continues to work as expected even with Java 11 as the baseline.

On Thu, Dec 3, 2020 at 8:57 AM Ullrich Hafner <ullrich...@gmail.com> wrote:
Are there already plans to move the Java baseline from Java 8 to Java 11 in the near future in Jenkins core?     

--
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/6BBCBBDB-FBCE-4210-BE0C-F3DA73777D8B%40gmail.com.

Oleg Nenashev

unread,
Dec 3, 2020, 7:33:41 PM12/3/20
to Jenkins Developers
Yes, the Java 11 adoption is still very low. It was around 30% last time I have seen the stats. Around 60% of users still run Java 8. With such a state it does not make sense to drop the Java 8 compatibility without really serious reasons which we IMHO do not have.

On a separate note, a few weeks ago we discussed moving to Java 11 in the default container tags (`latest`, `stable` and so on). Even in this case we were far from having a consensus, because it would require a coordinate update of agents and controllers by many Jenkins users.

BR, Oleg

Tim Jacomb

unread,
Dec 4, 2020, 2:35:09 AM12/4/20
to jenkin...@googlegroups.com
I would be definitely +1 for switching defaults and encouraging people to use jdk11

And not against updating the minimum version, people will move when they have to.

At my previous work we moved from 7 to 8 when we had to and it was no issue...

We’ve been on 11 for awhile here...

Java 8 is 6 years older at this point, yes a lots been backported but that doesn’t mean we should stay at it forever

Sonarqube recently moved to require java 11 as an example of one development tool that has gone there before us

Thanks
Tim


Ullrich Hafner

unread,
Dec 4, 2020, 3:43:29 AM12/4/20
to Jenkins Developers
Ok, I understand that. I wasn’t aware that so may people are still using Java 8. My students just ask me every time they want to contribute to my Jenkins plugins why they still need to use that old Java version ;-)

Am 04.12.2020 um 08:34 schrieb Tim Jacomb <timja...@gmail.com>:

I would be definitely +1 for switching defaults and encouraging people to use jdk11

And not against updating the minimum version, people will move when they have to.


The problem is that Oracle will provide support until 2030, that means nobody will be forced in the near future…

Gavin Mogan

unread,
Dec 4, 2020, 4:03:57 AM12/4/20
to Jenkins Developers
As a non java person, Is there any advantages in java 11 your looking forward to? ones that might encourage people to upgrade? I know streams and lambdas were nice in 8(?)

its my understanding that most things should now compile with java 11, but not bumping the minimum version yet.

Gavin


Daniel Beck

unread,
Dec 4, 2020, 5:06:15 AM12/4/20
to jenkinsci-dev


> On 4. Dec 2020, at 09:43, Ullrich Hafner <ullrich...@gmail.com> wrote:
>
> Ok, I understand that. I wasn’t aware that so may people are still using Java 8.

Jenkins stats (scroll down for recent months):

https://stats.jenkins.io/plugin-installation-trend/jvms.json

Obviously, Jenkins influences the stats here with what's on Docker images etc.; but still. Assuming the stats are correct, that's a tiny percentage of users on JDK 11, and IMO not enough to be confident about raising the requirement without potentially causing issues for a lot of users.

I suggest we get through tables-to-divs, X-Stream, and Acegi changes first and look at this again perhaps mid 2021.

Manuel Ramón León Jiménez

unread,
Dec 4, 2020, 5:33:04 AM12/4/20
to jenkin...@googlegroups.com
I love getting rid of old frameworks / libraries / ... to take advantage of all new stuff provides, but it's painful for users to migrate. The Java JDK is like changing your foundations and with all those new pain-potential changes we've made, I agree with Daniel, it's better to go little by little.

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

jn...@cloudbees.com

unread,
Dec 4, 2020, 5:55:34 AM12/4/20
to Jenkins Developers
>  is there any advantages in java 11 your looking forward to 

Personally I would change my code to use a HTTP client library that has async support, SNI, (all the things you expect) and not rely on a third party API that does not have stellar backwards compatibility :)

Matt Sicker

unread,
Dec 4, 2020, 11:35:49 AM12/4/20
to jenkin...@googlegroups.com
It may be important to note that requiring Java 11 to run Jenkins
doesn't mean you can't still use it to build Java 8 (or older!)
projects.

From a user point of view, I'd prefer that we can at least ensure that
Jenkins runs properly in the latest Java releases. Running a newer JVM
brings with it all the performance improvements over the past few
years, and it also natively supports TLS 1.3 which is fairly important
for HTTPS as well as for securing inbound remoting agents. The
HttpClient API is one of the nifty features provided since Java 11,
too, as already mentioned. Project Loom may turn out to be incredibly
useful for Jenkins. And then there's also potential that the JPMS API
might be useful for enhancing plugin class loader isolation.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5150b925-4f70-4de7-8bd6-793c5cfc1623n%40googlegroups.com.



--
Matt Sicker
Senior Software Engineer, CloudBees

Baptiste Mathus

unread,
Dec 4, 2020, 12:26:19 PM12/4/20
to Jenkins Developers
I agree with Daniel's take: delay to do something for real not before mid 2021. 
And I think we can still definitely love forward in the meantime on a plan.
Which this thread is great for brainstorming about (thanks Ulli).

For instance, we did switch ci.j.i to java 11 already.
I would think we want to plan ahead, start having an administrative monitor warning users for some months that the bump is coming if we detect a java 8 jvm, etc.

Is there anything else we could do to encourage more users to just upgrade by themselves, so when we bump the default values we have like 30% or less of instances running on java8?



Tim Jacomb

unread,
Dec 4, 2020, 1:27:25 PM12/4/20
to jenkin...@googlegroups.com
I think defaulting the docker images to java11 would be a good start 

Baptiste Mathus

unread,
Dec 4, 2020, 2:57:02 PM12/4/20
to Jenkins Developers
I agree but given the (often dangerously subtle) incompatibilities between agents and controllers when they run a different jvm, we should do this with a tight plan.

Maybe some of the features currently in version-column plugin should be put inside the core so alerts and guidance are more systematic if agent is running a different major version of the jvm than the controller's one.

Jesse Glick

unread,
Dec 4, 2020, 4:50:33 PM12/4/20
to Jenkins Dev
I am definitely opposed to trying to continue to “support” 8 if and
when we use 11 as a baseline for core. Let us be clear about what we
require and test against, so that we do not have a combinatorial
explosion of platforms. Plugins can be switched to run 11 in CI over
the course of a few months, and upgraded to `-source 11` as soon as
they decide to pick a new `jenkins.version`. (There is a bit of
infrastructure work needed for all this.)

Basing decisions on what portion of users currently run on 11 seems
circular. The interesting question is what portion of users _cannot_
run 11, for example due to some corporate mandate, and so would
actually refuse to upgrade Jenkins. This is harder to measure, of
course, but we can try.

I do not _think_ there is any problem running an agent on 11 while the
controller is on 8, or vice-versa, but it bears testing.

Last I tried using 11, there was still a lot of polish missing. The
agent printed a bunch of warnings about use of JDK internal classes.
IMO we should not be promoting use of a 9+ version until we can be
assured that no such warnings are printed when using testable features
of core or common plugins, perhaps by running `plugin-compat-tester`
and `acceptance-test-harness` with a JVM flag to turn on strict mode.
(JEP-228 means we are now on a version of XStream which at least
claims to get this right!)

Note that AdoptOpenJDK intends to support Java 8 for considerably
_longer_ than 11. And we should be at least testing against newer
versions including previews of 17 when they become available, lest we
move to 11 just as it is becoming obsolete.

Gavin Mogan

unread,
Dec 4, 2020, 9:03:51 PM12/4/20
to Jenkins Developers
I know there has been few/minor reports on IRC/gitter about agents having issues in 11 that were fixed going back to 8. I tried to encourage them to report issues, but I'm not sure they did.

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

Oleg Nenashev

unread,
Dec 5, 2020, 2:22:28 AM12/5/20
to JenkinsCI Developers
Last time I was testing cross-JVM mode (Java 8 agents + Java 11 controller), it passed smoke tests I had. I am pretty sure there are class serialization edge cases, but it should be solvable.

As Jesse said, the main concern is about warnings being printed here and there. JVM access and illegal reflective access mostly. On 2.263 there are a few hundreds being printed, mostly from XStream and from Pipeline internals. XStream unforking should help.

Best regards,
Oleg  


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/nEw4TLDcZLw/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/CAG%3D_DuuJ30tFYmFu2wRiU5n2%3DRpcrZHgivLEfDfrTQ3g1i5mrQ%40mail.gmail.com.

Matt Sicker

unread,
Dec 7, 2020, 10:34:56 AM12/7/20
to jenkin...@googlegroups.com
FWIW, whenever I need to set up some sort of integration testing with
Jenkins, I'm usually using Java 11 as it's what's most easily
installable on Linux and Windows. The only incompatibilities I've come
across so far have been old fixed issues in maven-hpi-plugin when
trying to compile old plugins.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCiCTS%2B%2BQxAnuDc4_A021EwoNJ%3DMzAjmNGgfbJL5mF17Q%40mail.gmail.com.

James Nord

unread,
Dec 7, 2020, 1:26:31 PM12/7/20
to jenkin...@googlegroups.com
>   and it also natively supports TLS 1.3 which is fairly important
for HTTPS as well as for securing inbound remoting agents.

FTR that should be available in recent OpenJDK releases.
https://bugs.openjdk.java.net/browse/JDK-8245466


Matt Sicker

unread,
Dec 7, 2020, 2:14:45 PM12/7/20
to jenkin...@googlegroups.com
Oh neat, that's good news! I hope they backport their ChaCha cipher
code, too, because that's still only supported by BouncyCastle
otherwise for Java 8 as far as I'm aware.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPzq3pfcvHqotN7_yjXn5XXt89WOXbcgTAP55dy1p_cJyhV8PA%40mail.gmail.com.

Matt Sicker

unread,
Dec 7, 2020, 10:18:39 PM12/7/20
to jenkin...@googlegroups.com
Jetty 10 requires Java 11, so there’s one concrete reason to upgrade sometime.

timja...@gmail.com

unread,
Dec 13, 2020, 6:21:35 AM12/13/20
to Jenkins Developers
Initial attempt here to fix most of the warnings:

Rest of the warnings are caused by groovy and guice, at least on the controller startup.

timja...@gmail.com

unread,
Jan 6, 2021, 3:23:10 AM1/6/21
to Jenkins Developers
Brief update on this:

* Mark has updated the website to use Java 11 install instructions
* Core caused illegal reflective access warnings PR is merged
* Stapler illegal reflective access was released in 2.273
* Remaining warnings are mostly caused by groovy which requires some work to upgrade, https://github.com/jenkinsci/jenkins/pull/5112#issuecomment-744429487 and https://github.com/jenkinsci/jenkins/pull/5116#issuecomment-744526638 for background
* I've updated a bunch of old plugins to build and test on java 11 as part of tables to divs fixes
* I'm running on java 11 entirely now, and fixing any issue I hit, mostly very minor.

I agree with Jesse that we should start testing against Java 17 when the previews are released and I'm happy to help with the infra side of that

Thanks
Tim

Oleg Nenashev

unread,
Jan 7, 2021, 3:47:56 AM1/7/21
to Jenkins Developers
> Jetty 10 requires Java 11, so there’s one concrete reason to upgrade sometime.

For sure. Right now there is no timeline for 9.x deprecation, but it is likely to become a less maintained baseline with mostly backports. Actually it may make Jetty more stable for a while, but there will be growing pressure to update.

> Java 17

+1 for testing with Java 17. If it becomes LTS, we will need to eventually support it. Infra side is relatively straightforward though many patches will be needed. Good news is that, compared with Java 11, now we have an opportunity to utilize Plugin BOM for initial smoke testing. It allows to smoke test a lot of key plugins at once without massive rework.
Reply all
Reply to author
Forward
0 new messages