Ping 😅

Hi @aalmiray, I'm not an expert about this and I'd like to understand the benefits, so I have a question:

This will help modular projects that consume artifacts from this specification, specifically those that create custom Java Runtimes with jlink, as the latter does not support automatic modules but explicit modules.

are we saying that currently we cannot use the SDK with jlink?
I used to use jlink with previous versions of the SDK and it worked https://github.com/knative-sandbox/eventing-kafka-broker/blob/release-1.5/data-plane/docker/generate_jdk.sh

It depends. Automatic module names do not work with jlink by design. This means modules as currently defined by this SDK cannot be used to generate a modular Java Runtime that contains said modules.

However an hybrid distribution (modular Java Runtime + external automatic modules and/or non modular JARs) may be created. Not that many people know that hybrid JRs may be created nor the steps required to create them. Most people either go full modules or not at all when dealing with jlink.

Feel free to propose a PR

…Not that many people know that hybrid JRs may be created nor the steps required to create them…

It would be super, super cool @aalmiray, if you could share with the community a link that explains those steps. Please?

TIA.

Have not found a blog post explaining hybrid JRs. However, there have been a couple of posts detailing how to build a small JR with jlink for applications packaged inside a container; they provide the basics. Here's why.

Most people think you must have a fully modular application to reap the benefits of jlink. But not necessarily. You can create a minimal JR containing a subset of modules from the original JDK. The application doesn't have to be modular, hence its JARs are shipped with the JR.

This is the basis for the hybrid approach as the only change needed is to find out if any of the application's JARs are modular. Those that are modular could be added to the JR, which removes them from the directory containing the JARs, resulting in a JR with JDK & app modules.

JRs built in this way still require applications to be run in classpath mode because they are not modular. The advantage of building hybrid JRs is sharing a common base among similar applications.

However, you may think of custom JRs in the same way as we do with container layers. It might be better to build a minimal JR (only JDK modules) as a base layer, all app JARs as a second layer.

@pierDipi PR #574 is ready for review