cloudevents
Support full Java Module descriptors
v2.4.2 defines automatic module names for all Maven modules
$ jarviz module name --gav io.cloudevents:cloudevents-core:2.4.2
subject: cloudevents-core-2.4.2.jar
name: io.cloudevents.core
source: manifest
automatic: true
valid: true
$ jarviz module descriptor --gav io.cloudevents:cloudevents-core:2.4.2
subject: cloudevents-core-2.4.2.jar
name: io.cloudevents.core
version: 2.4.2
open: false
automatic: true
requires:
java.base mandated
contains:
io.cloudevents.core
io.cloudevents.core.builder
io.cloudevents.core.data
io.cloudevents.core.extensions
io.cloudevents.core.extensions.impl
io.cloudevents.core.format
io.cloudevents.core.impl
io.cloudevents.core.message
io.cloudevents.core.message.impl
io.cloudevents.core.provider
io.cloudevents.core.v03
io.cloudevents.core.v1
I'd be great if the library supplied full Java module descriptors. It's possible to keep bytecode baseline compatible with Java 8 while providing a full module descriptor thanks to ModiTect. 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.
I've checked all artifacts provided in cloudevents-bom-2.4.2 and there are no split packages.
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.
…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.