Add module-info.java
jan-tosovsky-cz opened this issue · comments
When SparseBitSet is used as dependency, the parent project can't be processed by jlink, which rejects dependencies with automatic module names.
Adding module-info.java with this content could fix this:
module com.zaxxer.sparsebits {
exports com.zaxxer.sparsebits;
}
While adding an automatic module name solves some issues with building modular applications, it does not help with jlink. Jlink is used to create a custom stripped down runtime environment for modular applications.
The purpose of a module-info file is to inform what module the jar declares (so that other modules can use it in requires statements and make sure that it is accessible) and to inform what other modules this module depends on. An automatic module name just solves the first issue. It is needed for compiling modular applications. Since it cannot be determined what other modules a modules depends on when using an automatic module name, it is assumed that a modules with an automatic module name depends on all other modules. Since that would require jlink to pull in the full JDK every time a module with an automatic module name is used, that would void the whole effort of using jlink in the first place, hence modules with an automatic module name are disallowed by jlink.
This can be solved by providing a "real" module-info.class. This can be done in a multi-release jar, so that Java 8 applications can use the jar without problems, or by setting the minimum required JDK version to 9+. I would suggest setting the required JDK version to 11, as versions 9 and 10 are obsolete now and wherever still used, the update should only require setting the new version in the Maven POM/Gradle build file.
While there might be projects still using Java 8, they could stay on version 1.3 of this library.
I'd be willing to contribute a patch/PR to change minimal Java version to 11 and provide a module-info.java file if there's a chance that would be accepted and a new version 1.4 could be released.
I think it would be good considering to have 2 branches, one to continue supporting java 8 (1.x.x) and other one to support java 11|17|21 (2.x.x). In that way bug-fixes will not be exclusive of java11 or newer
@xavier-figueroa I created a minimal PR to add a real module-info. The patch retains java 6 compatibility. But projects downstream that want to be jlink compatible need a working module-info first, and I think not breaking backwards compatibility increases the chances of getting this in.