Jenkins, an open source Devops tool, announced: Starting with the June 28th release of Jenkins 2.357 and the upcoming September LTS release, Jenkins requires Java 11 as a minimum.
Originally known as Hudson, Jenkins is a venerable continuous integration tool that has been in existence for over a decade. Since its inception in 2005, the Jenkins project has undergone several Java migrations. The current migration from Java 8 to Java 11 is consistent with the migration history in the Jenkins project.
Developer Basil Crow explained in a blog post that the Jenkins project may remain on Java 8 in the short term, but doing so would do more harm than good for several reasons. First, many of the key third-party libraries used by the Jenkins project (e.g., Jetty, JGit, Spring Framework, and Spring Security) are starting to require newer versions of Java, and staying on Java 8 will prevent the Jenkins project from receiving security updates from upstream projects.
In addition, new versions of Jaba make significant runtime improvements to the Java platform. For example, LinkedIn saw significant performance improvements when migrating to Java 11, Adoptium saw significant memory usage improvements when migrating to Java 11 (also on Jenkins), and the recent Java runtime provides many improvements to garbage collection.
Finally, keeping the current version of Java helps Jenkins attract and retain developers.
Currently, the official Jenkins Docker image has been based on Java 11 for several months, Java 8 is available as an alternative for now, and Java 17 is available in preview mode. However, starting with Jenkins 2.357, Java 8 images are being phased out and Java 17 images are being transitioned from preview to general availability (GA).
In fact, the Jenkins team recommends that users use Java 17.
Jenkins support for Java 17 is new, though it has not yet reached the stage of general adoption within the Jenkins community.
Nevertheless, our experience is that Java 17 is a more reliable choice than Java 11, andwe can confidently say that migrating from Java 11 to Java 17 will not be as painful as migrating from Java 8 to Java 11.