Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support full Java Module descriptors #555

Open
aalmiray opened this issue Apr 27, 2023 · 7 comments · May be fixed by #574
Open

Support full Java Module descriptors #555

aalmiray opened this issue Apr 27, 2023 · 7 comments · May be fixed by #574

Comments

@aalmiray
Copy link

aalmiray commented Apr 27, 2023 •
edited

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.
@aalmiray aalmiray mentioned this issue Apr 27, 2023
Open
@aalmiray
Copy link
Author

Ping 😅

@pierDipi
Copy link
Member

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

@aalmiray
Copy link
Author

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.

@pierDipi
Copy link
Member

Feel free to propose a PR

@aalmiray aalmiray linked a pull request May 23, 2023 that will close this issue
Open
@skepticoitusInteruptus
Copy link
Contributor

…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.

@aalmiray
Copy link
Author

aalmiray commented Jun 3, 2023

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.

aalmiray added a commit to aalmiray/cloudevents-sdk-java that referenced this issue Feb 13, 2024
@aalmiray
Add full Java module descriptors
e532206 
Closes cloudevents#555

Signed-off-by: Andres Almiray <aalmiray@gmail.com>
@aalmiray
Copy link
Author

@pierDipi PR #574 is ready for review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: Add full Java module descriptors aalmiray/cloudevents-sdk-java
3 participants
@aalmiray @pierDipi @skepticoitusInteruptus