Don't use `jlink` in newer JDKs images until properly tested

[lemeurherve]

Not easy to integrate nor fully verified on new JDK support:

• From @gounthar in feat(linux): add support on Linux for JDK 25 preview in Docker build configurations #1024 (comment):

  From the PR body,

  Changed the Java runtime image creation with JDK 25-specific module and compression settings on Linux and Windows images.

  Question: what's the reasoning behind the choice of these particular modules? Does it have to be different from the other cases?

  Starting with JDK 24, you can't import all modules into jlink anymore. You must select and list the ones you need. I've included the bare minimum for my use case, but there's no guarantee it will suffice. Time and user feedback will determine its adequacy.

• From @lemeurherve in feat: add JDK25 images docker#2146 (comment):

  There is a closed Jetty issue that mentions FileSystemNotFoundException:

  • java.nio.file.FileSystemNotFoundException when creating a resource from a JAR URL jetty/jetty.project#10274

  Doesn't look relevant, this seems to be it: https://stackoverflow.com/a/77115516/4951015

  Adding jdk.zipfs like in 7a58917 isn't enough unfortunately, failing on boot with hudson.util.IncompatibleVMDetected:

• From @dduportal in feat: add JDK25 images docker#2146 (comment):

  Is there a reason against starting with the full JDK? Yes I know we can get a few megabytes less by "generating" our own JDK. But it looks like a lot of trouble (on each JDK upgrade we have this kind of exchange) and a lot of risks (what if our tests do not cover all cases using JDK modules) while we could already provide something to the end users?

  I would prefer having the discussion at SIG platform level. I believe we should automate testing a "stripped" JDK way earlier than in the Docker image which is only packaging. If ci.jio could run some ATH branches which runs with stripped (and documented) JDKs, that would feel safer and easier to "only" reproduce here.

And potentially causing issue:

• From @jonesbusy in feat(linux): add support on Linux for JDK 25 preview in Docker build configurations #1024 (comment)

  I'm investigating a bug that occur on Java 25 (all container, both controller and agent).

  The httprequest plugin fail all request via apache-httpcomponents-client-5-api

  [16:25:10.392+01:00] - java.lang.ExceptionInInitializerError: Exception java.lang.NoClassDefFoundError: jdk/net/Sockets [in thread "samples-ci-dotnet-core-main-225-sxrcq-djzx4-w70wq [#11] for JNLP4-connect connection to elca-jenkins-agent/172.30.70.87:50000 id=2054"]
  [16:25:10.392+01:00] - 	at PluginClassLoader for apache-httpcomponents-client-5-api//org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.<clinit>(DefaultHttpClientConnectionOperator.java:87)
  

  Don't we need jdk.net as well?

  I will try to investigate and document my findings

We should remove the use of jlink (at least for new JDKs like JDK25 until proven flawless) in controller and agents images until we have a way to properly test it.

WDYT?

[timja]

At least on old JDKs it saves a lot of space and is the recommended deployment model.

I don't think it would be especially hard to create a list of modules that work for most cases. Or re-creating the old modules path.

[lemeurherve]

I agree, but until we have a process to properly test its use and integration, my opinion is that we should avoid using jlink in JDK25 agents images (like current JDK25 controller image).

[dduportal]

At least on old JDKs it saves a lot of space and is the recommended deployment model.

Do you have documentation explaining the recommended deployment model? It would greatly help to optimize our images/packages but with a reference.

[timja]

Bit of info here: https://adoptium.net/en-GB/news/2021/08/using-jlink-in-dockerfiles and https://adoptium.net/en-GB/news/2021/12/eclipse-temurin-jres-are-back.

Looks like there was a push a few years ago and less recent references.

At the time it was saving 200mb which on an image that is pulled really often is a lot: jenkinsci/docker#1185

[gounthar]

I guess that if we go with “let’s get rid of the JLink usage,” we’ll never really take the time to properly investigate which modules were missing.

What about adding the missing one that Valentin identified and then moving on?

[jonesbusy]

Meanwhile: #1127

[lemeurherve]

I guess that if we go with “let’s get rid of the JLink usage,” we’ll never really take the time to properly investigate which modules were missing.

What about adding the missing one that Valentin identified and then moving on?

Meanwhile: #1127

The problem I see going that way and why I opened this issue is that we still currently don't have a way to properly test the resulting image to ensure we're not missing any modules cf the error found by @jonesbusy cf #1024 (comment)

So yes we should definitively put some effort to use jlink to publish smaller images, but IMO it has to be done properly.

In other words, coming up with and implementing a proper testing and validation process first, as jlink becomes harder and harder to properly implement with newer JDKs cf refs in this issue body.

[lemeurherve]

[...] the error found by @jonesbusy cf #1024 (comment)

@jonesbusy would you mind opening a dedicated issue describing the error you found please?
That would be helpful as reference here and for #1127, and easier for you to add details if you're the author of that issue.

EDIT: reposted in your PR at #1127 (comment), kinda off-topic here.

[lemeurherve]

FWIW, related refs about jlink I found during my initial work on jenkinsci/docker#2146 cf jenkinsci/docker#2146 (comment):

• https://adoptium.net/en-GB/news/2025/08/eclipse-temurin-jdk24-JEP493-enabled
• https://openjdk.org/jeps/493