Proposal: Allow requiring Java 10+ for building Jenkins components

[Oleg Nenashev]

Hi all,

As a part of the Jenkins & Java 10+ hackathon
<https://jenkins.io/blog/2018/06/08/jenkins-java10-hackathon/> we
discovered a need to introduce Multi-release JARs
<http://openjdk.java.net/jeps/238> in some components in order to utilize
better APIs available in Java 9 and above. It was mostly required for
cleanup of Illegal Reflective Access warnings, but in some cases it also
allows to utilize better APIs without breaking compatibility with older
Java versions. E.g. there is
https://github.com/jenkinsci/lib-process-utils/pull/3 from Nicolas de Loof
(see his blogpost
<https://blog.loof.fr/2018/06/multi-release-jar-with-maven.html> for more
info about the approach).

Background:

- In medium-term after the Java 11 LTS release Oracle is about stopping
shipping official older OpenJDK releases to non-commercial customers, and
we may be interested to get ready to that
- During the hackathon a number of contributors (Nicolas, Sam van Oort,
Devin Nusbaum, Olivier Lamy, Jeff Thompshon, etc.) investigated Jenkins
tooling issues and solved some compatibility issues, and we are getting
close to being able to build Jenkins core and plugins on JDK10
- During the Hackathon Olivier Vernin has added support of JDK10 to
ci.jenkins.io, so our infrastructure is probably ready

Proposal:

- Allow requiring JDK 10+ to *build* Jenkins components
- It includes Jenkins core libs, plugins and potentially the core
itself
- It's up to maintainers to decide when they are ready to accept such
requirement in components they maintain
- Require such components to retain compatibility with Java 8 (as
long as Jenkins Core supports it)
- Require such components to have Jenkinsfiles running tests on Java 8
and Java 10+
- Be explicit that all Java 10+ support is available in the experimental
mode until Jenkins officially supports it (currently we consider Java 10/11
support as a preview mode - docs
<https://jenkins.io/doc/administration/requirements/java/#running-jenkins>
)

What do you think?
I could create an info JEP for it if it makes sense in this case. Probably
too much overhead.

Best regards,
Oleg

[nicolas de loof]

- Allow requiring JDK 10+ to *build* Jenkins components
- It includes Jenkins core libs, plugins and potentially the core
itself
- It's up to maintainers to decide when they are ready to accept such
requirement in components they maintain


- Require such components to retain compatibility with Java 8 (as long
as Jenkins Core supports it)
- Require such components to have Jenkinsfiles running tests on Java 8
and Java 10+
- Be explicit that all Java 10+ support is available in the experimental
mode until Jenkins officially supports it (currently we consider Java 10/11
support as a preview mode - docs
<https://jenkins.io/doc/administration/requirements/java/#running-jenkins>
)


I fully agree with this approach.

Post by Oleg Nenashev
Hi all,
As a part of the Jenkins & Java 10+ hackathon
<https://jenkins.io/blog/2018/06/08/jenkins-java10-hackathon/> we
discovered a need to introduce Multi-release JARs
<http://openjdk.java.net/jeps/238> in some components in order to utilize
better APIs available in Java 9 and above. It was mostly required for
cleanup of Illegal Reflective Access warnings, but in some cases it also
allows to utilize better APIs without breaking compatibility with older
Java versions. E.g. there is
https://github.com/jenkinsci/lib-process-utils/pull/3 from Nicolas de
Loof (see his blogpost
<https://blog.loof.fr/2018/06/multi-release-jar-with-maven.html> for more
info about the approach).
- In medium-term after the Java 11 LTS release Oracle is about
stopping shipping official older OpenJDK releases to non-commercial
customers, and we may be interested to get ready to that
- During the hackathon a number of contributors (Nicolas, Sam van
Oort, Devin Nusbaum, Olivier Lamy, Jeff Thompshon, etc.) investigated
Jenkins tooling issues and solved some compatibility issues, and we are
getting close to being able to build Jenkins core and plugins on JDK10
- During the Hackathon Olivier Vernin has added support of JDK10 to
ci.jenkins.io, so our infrastructure is probably ready
- Allow requiring JDK 10+ to *build* Jenkins components
- It includes Jenkins core libs, plugins and potentially the core
itself
- It's up to maintainers to decide when they are ready to accept
such requirement in components they maintain
- Require such components to retain compatibility with Java 8 (as
long as Jenkins Core supports it)
- Require such components to have Jenkinsfiles running tests on Java 8
and Java 10+
- Be explicit that all Java 10+ support is available in the
experimental mode until Jenkins officially supports it (currently we
consider Java 10/11 support as a preview mode - docs
<https://jenkins.io/doc/administration/requirements/java/#running-jenkins>
)
What do you think?
I could create an info JEP for it if it makes sense in this case. Probably
too much overhead.
Best regards,
Oleg

[Jesse Glick]

E.g. there is https://github.com/jenkinsci/lib-process-utils/pull/3

Requiring major changes to the Jenkins core build system, including
new tool versions on both CI and developer machines as well as more
complex POMs and binaries, seems like a poor tradeoff when the above
example can be done without any new infrastructure in a few lines of
runtime code (that people can actually debug directly).

I can see a use case for the compile-type checking that comes with
multirelease JARs if you really have a large body of code making
numerous complex calls to APIs available only in a newer Java
platform. For example, Java 7 introduced NIO APIs which were broadly
useful and applicable to many components in Jenkins, and it would be
unwieldy to call them reflectively. But is that really the case yet
for Java 9–11, or are we just talking about a handful of new methods
here and there? And if it is the case that there are massive new APIs
we want to be using across the board, then I would argue we should
simply drop Java 8 compatibility and require 11 at some point after
its release. Or use Animal Sniffer, which is not perfect (you do not
get compile-time verification that methods marked
`@IgnoreJRERequirements` are in fact compatible with the older
platform), but is at least simple and nonintrusive beyond mandating
tool updates.

[nicolas de loof]

this sample multi-release jar is a very minimal one, mostly used here to
demonstrate the concept and usage.
I can expect we get some more complex implementation for concrete java 9+
compatibility issues.

Post by Jesse Glick

E.g. there is https://github.com/jenkinsci/lib-process-utils/pull/3

Requiring major changes to the Jenkins core build system, including
new tool versions on both CI and developer machines as well as more
complex POMs and binaries, seems like a poor tradeoff when the above
example can be done without any new infrastructure in a few lines of
runtime code (that people can actually debug directly).
I can see a use case for the compile-type checking that comes with
multirelease JARs if you really have a large body of code making
numerous complex calls to APIs available only in a newer Java
platform. For example, Java 7 introduced NIO APIs which were broadly
useful and applicable to many components in Jenkins, and it would be
unwieldy to call them reflectively. But is that really the case yet
for Java 9–11, or are we just talking about a handful of new methods
here and there? And if it is the case that there are massive new APIs
we want to be using across the board, then I would argue we should
simply drop Java 8 compatibility and require 11 at some point after
its release. Or use Animal Sniffer, which is not perfect (you do not
get compile-time verification that methods marked
platform), but is at least simple and nonintrusive beyond mandating
tool updates.
--
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
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0ujCaoy9WhLLrDUQRh_seS6rOQ9pLqwri0YQ_gKE%2B1Kg%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

[Oleg Nenashev]

Maybe we should add an explicit requirement. E.g. "if a downstream
component includes Java 9+ bits (e.g. lib-process-utils), downstream
components (e.g. Jenkins core for lib-process-utils) must be still
buildable and testable with JDK8"

Such requirement would greatly limit the impact on the project.

BR, Oleg

Post by nicolas de loof
this sample multi-release jar is a very minimal one, mostly used here to
demonstrate the concept and usage.
I can expect we get some more complex implementation for concrete java 9+
compatibility issues.

Post by Jesse Glick

E.g. there is https://github.com/jenkinsci/lib-process-utils/pull/3

Requiring major changes to the Jenkins core build system, including
new tool versions on both CI and developer machines as well as more
complex POMs and binaries, seems like a poor tradeoff when the above
example can be done without any new infrastructure in a few lines of
runtime code (that people can actually debug directly).
I can see a use case for the compile-type checking that comes with
multirelease JARs if you really have a large body of code making
numerous complex calls to APIs available only in a newer Java
platform. For example, Java 7 introduced NIO APIs which were broadly
useful and applicable to many components in Jenkins, and it would be
unwieldy to call them reflectively. But is that really the case yet
for Java 9–11, or are we just talking about a handful of new methods
here and there? And if it is the case that there are massive new APIs
we want to be using across the board, then I would argue we should
simply drop Java 8 compatibility and require 11 at some point after
its release. Or use Animal Sniffer, which is not perfect (you do not
get compile-time verification that methods marked
platform), but is at least simple and nonintrusive beyond mandating
tool updates.
--
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
To view this discussion on the web visit https://groups.google.com/d/
msgid/jenkinsci-dev/CANfRfr0ujCaoy9WhLLrDUQRh_
seS6rOQ9pLqwri0YQ_gKE%2B1Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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/siXHvpEJE5U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
To view this discussion on the web visit https://groups.google.com/d/
msgid/jenkinsci-dev/CANMVJz%3Dnfn7jFVS3o8JXQ6BuGAO77qEwBjM
Xw2Uteit77VdDFQ%40mail.gmail.com
<https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3Dnfn7jFVS3o8JXQ6BuGAO77qEwBjMXw2Uteit77VdDFQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.