-
-
Notifications
You must be signed in to change notification settings - Fork 21
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.
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
Support Java Modules #64
Comments
I'm not the maintainer, but imho supporting modules fully is not worth the effort for this library. That being said, this is just my personal opinion. Feel free to correct me if I missed something 😄 |
True. cdevents could switch to other slf4j implementations such as |
v1.2.25
defines an automatic module nameI'd be great if the library supplied a full Java module descriptor. 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 this library, specifically those that create custom Java Runtimes with
jlink
, as the latter does not support automatic modules but explicit modules.ModiTect requires Java 9 to be used for running the build. Reload4j currently targets Java 5 bytecode. I think it might not be possible to use the plugin directly. The alternative would be to have an additional source set containing
moudle-info.java
compiled with Java 9+, then merge all classes into a single JAR.module-info.class
should be placed in the versioned space (META-INF/versions/x
) and aMulti-Release: true
attributed added to the JAR's manifest.If this feature is added then
slf4j-reload4j
would also need to be made fully modular (can't open a ticket at jira.qos.ch to file it at this moment).The text was updated successfully, but these errors were encountered: