Platform SIG - Jun 17, 2022

Community
,
1

2022-06-17T15:00:00Z

2022.06.17 - Java 11, Java 17

Attending:

  • Mark Waite
  • Basil Crow

Recording:

Agenda:

  • Open action items
    • Plugin installation manager docs - PR-4373 (closed)
      • Docs team agrees with Tim that a simple use case will be described on www.jenkins.io and detailed documentation will be kept in the GitHub repository of the tool
        • No change since last meeting, no change expected soon
  • Require Java 11 or newer for Jenkins core
    • Timeline
      • June 28, 2022 - first weekly release to require Java 11, no Java 8
        • Basil hopes for a blog post very soon, working on it
        • See docs office hours notes and Jira
      • Sep 2022 - first LTS release to require Java 11
  • Java 17 support in Jenkins
    • Blog post will announce general availability of Java 17 support
      • Few people using Java 17 due to preview mode (special flag)
      • Removing the flag from the LTS release 2.346.1
      • Encourage more use of Java 17 for those who are interested
      • Java 17 feels like a better release than Java 11
        • Several bugs fixed in Java 17 that needed backport to Java 11
        • Would choose Java 17 rather than Java 11 with new release
        • Encourage wider testing and exploration with Java 17
      • Plugin Compat Tester passes on top 100 plugins
        • Risk that a favorite plugin doesn’t support Java 17
        • Common issues with plugins using XStream to serialize concurrent Java types (like ConcurrentHashMap)
          • Usually indicates a bug or design flaw in code
          • Serializing a concurrent type to XML is atypical
          • Writing the concurrent data structure to disk is not usually what you want
            • Converted field from concurrent to regular data structure then manage the locking elsewhere
          • Rare issues in rather obscure cases
        • Not expecting many Java 17 problems, but likely will be some
      • Plugin maintainers should run their tests with Java 17
        • Checks Java 17 compilation and runtime
      • Known bug in groovy jelly views that can affect certain types
        • Interesting programming language bug, but only one known manifestation of the bug (already worked around)
        • If it becomes a more common issue, then resolve the root issue
1 Like
2

While a lot of companies are already adapting Java 17 now I wonder why we still put in a lot of extra effort to make Jenkins Java 11 compatible right now. Wouldn’t it make more sense to directly jump to Java 17?

3

We have several years of experience running production Jenkins instances with Java 11, including ci.jenkins.io and several variants of it (trusted, release, cert, etc.). We aren’t running any production Jenkins instances in the Jenkins project with Java 17. I think that skipping Java 11 for Java 17 is too large a risk for many Jenkins users.

We could switch weekly.ci.jenkins.io from Java 11 to Java 17 after next week’s release. I don’t think that the project is ready to switch other production instances to Java 17 yet.

4

I enthusiastically recommend Java 17 to Jenkins users, as I have discovered many issues in Java 11 that have been fixed in Java 17. At the time of this writing, it has been 8 days since I had to backport a fix from Java 17 to Java 11. I am more confident in the quality of the Java 17 runtime than I am in the quality of the Java 11 runtime.

That having been said, Mark is correct that Jenkins itself has not been deployed widely on Java 17, and there are two known categories of problems (discussed in the above meeting) that are difficult to scan for and specific to running Jenkins on Java 17. We would need wider adoption of Jenkins on Java 17 to be confident that more of these problems do not exist.

As my forthcoming blog post about Java requirements will explain, the Jenkins project has historically not required a new Java version until adoption of the preceding version is in a decline. Adoption of Java 17 has not even reached a peak, so requiring Java 17 would go against historical precedent.

The Oracle Java 11 EOL is September 2023 and the Red Hat / OpenJDK / Adoptium Java 11 EOL is October 2024, so if we want to be consistent with historical precedent, we better get users up to adopt Java 17 quickly. I will be pushing for this aggressively. We have already backported Java 17 support to 2.346.1, and I will be lobbying to get ci.jenkins.io upgraded to Java 17 as well.

2 Likes
5

Many thanks for this awesome work!

The infra team could absolutely start trying to user JDK17 on our private controller quite soon.
We need to check the “actual known issues” to be sure it would not cause too much trouble at first, but could also be really a way to provide valuable insights WDYT?

6

What actual known issues? I am not aware of any.

7

That is really good news! For info, I’ve just opened [infra.ci.jenkins.io] Start using JDK17 · Issue #3072 · jenkins-infra/helpdesk · GitHub .