-
Story
-
Resolution: Fixed
-
Minor
-
-
Evergreen - Milestone 2
Problem
OpenJDK has not provided yet a base Alpine image for JDK 11.
And it's not going to happen
https://twitter.com/mreinhold/status/1046862466204950529 (Mark Reinhold is Chief Architect of the Java Platform Group)
It might happen for JDK 12, as written in that tweet, but it's a might.
This means we current cannot upgrade the JDK currently set up from 8 to 11 without more than consistent efforts. And even if we achieve to do it, this is quite out of scope, and dangerous for users, for the Jenkins Project to actually offer an openjdk build on Alpine, given even the official OpenJDK image is not doing it!
This is even more an issue because the JDK release cadence has accelerated. JDK 12 is already coming, and JDK 13 is expected in September 2019 (https://openjdk.java.net/projects/jdk/13/spec/).
Acceptance Criteria/Expected
- Evergreen should use a platform that makes upgrading the JDK a no-brainer (managing the build of the JDK for Alpine is not the mission of the Jenkins Project)
Technical note
The new target platform/base image is not defined yet. Some people argue for Debian, some Ubuntu, some Centos/Fedora. There will probably be some discussion about this at some later point.
- links to
[JENKINS-55547] Change base image for Evergreen (move away from Alpine)
Stewart X Addison
added a comment - AdoptOpenJDK.net provide "clean" openjdk builds with Alpine docker images at https://hub.docker.com/r/adoptopenjdk/openjdk11 and https://hub.docker.com/r/adoptopenjdk/openjdk11-openj9
Would be great if you guys would take our images. Feel free to reach out to us here, our slack instance, or on twitter (I'm sxaTech there). I'm not our main docker person but we're happy to work with you 
Stewart X Addison
added a comment - AdoptOpenJDK.net provide "clean" openjdk builds with Alpine docker images at https://hub.docker.com/r/adoptopenjdk/openjdk11 and https://hub.docker.com/r/adoptopenjdk/openjdk11-openj9
Would be great if you guys would take our images. Feel free to reach out to us here, our slack instance, or on twitter (I'm sxaTech there). I'm not our main docker person but we're happy to work with you
Another reason that I would really like this handled rather sooner than later: recently, I was trying to make sure artifact-manager-s3 and overall the EC2 Evergreen flavor would work correctly on JDK 11.
So my initial idea was to simply spawn an Evergreen instance the usual way, then hack into it, wget a JDK11, tweak PATH and restart the instance to force it to use JDK11. I was expected it to take a handful of minutes.
But then I remembered given the instance was based on Alpine this was going to be actually very hard. So I stopped trying because that was out of scope for the time/effort I had planned.
I think Alpine is a nice effort, but the μlibC starting from scratch is starting to show its shortcomings. The effort is not shared, and as soon as, as right now, it got an issue to support something (the JDK in our case), things simply stalled.
Now, there are many possibly flavors to choose from. Debian, Ubuntu, Centos...
TL;DR: I'm going to go for Centos for the following reason: Centos is downstream to RHEL and Fedora, who are handled by a group of people that have the Java Platform working correctly at the core of their concerns. (I could probably go for Fedora, for a similar reason as explained above, I don't feel that strongly for Centos or Fedora, BTW).
Ubuntu
Ubuntu has recently made a choice to provide a package for Java 11, but actually have Java 10 in it: https://askubuntu.com/questions/1037646/why-is-openjdk-10-packaged-as-openjdk-11
The rationale being: people would automatically this way automatically bump to Java 11 (because the package was actually name ...-lts) once it got published...
I feel like these people, though basing this choice to help others, may not understand deeply enough the requirements and differences between two different major versions of the JDK.
I think unfortunately this kind of action illustrates why we should move away from Debian based distributions. And this comes from someone who's been a Debian fanboy for years, and still very much likes it for a development machine, etc. Just that the overall platform does not look like (anymore?) the best possible default choice for running Java based software in production.
Debian
Recently, another issue arised where showing Debian would backport fixes in a potentially different way than openjdk (which can make it pretty different from other platforms): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
This one surfaced in https://twitter.com/jroper/status/1062869489073573888?lang=en :
This one is also known/surfaced as SUREFIRE-1588, which has been discussed extensively in many locations and took a lot of effort to get rid of in the Jenkins ecosystem and elsewhere: https://github.com/jenkinsci/pom/pull/34 https://github.com/jenkinsci/plugin-pom/pull/131 https://github.com/jenkinsci/plugin-compat-tester/pull/93 https://github.com/jenkinsci/plugin-pom/pull/135 https://issues.apache.org/jira/browse/SUREFIRE-1588?focusedCommentId=16704836&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16704836
Given Jenkins is fully written in Java, I believe platform produced by teams that have deep roots in the Java ecosystem are better choices for Jenkins.