-
-
Notifications
You must be signed in to change notification settings - Fork 301
Multi release JAR support design discussion
Bnd needs updates to support building of Multi-Release JARs.
Currently Bnd is unaware of MRJARs and complains about classes under META-INF/versions/. A related issue is that Bnd will include the module-info.class in the root of the bundle in the EE calculation when it really should not.
Java 9 introduced the concept of multi-release jars to support changes in the Java class libraries as APIs are removed (e.g. to Jakarta EE) or changed (in support of better encapsulation.) So the goal of multi-release jars is not to support adding incremental API for use in later Java releases, but to support class implementations having to vary to support multiple versions of Java in the face of Java class library API changes. The same class may thus have multiple implementations where the proper variation is selected at runtime based upon the version of Java in use.
The public API exported by the classes in a multi-release JAR file must be exactly the same across versions
A bundle can contain resource in the main jar as well as in directories and embedded jars along the Bundle-Classpath. The OSGi specification calls these "containers". The main jar is a container and each entry of the Bundle-Classpath also a container. (Only the main jar supports Bundle-Classpath. Other containers on the Bundle-Classpath are not treated as OSGi bundles and thus not processed for Bundle-Classpath.)
The OSGi specification allows for each container to be multi-release. Being a multi-release container is declared by the presence of Multi-Release: true in the manifest of the container. Each container in the bundle can be multi-release or not multi-released. So there can be a mixture.
When the main container is multi-release, the OSGi specification supports supplemental manifest information in the META-INF/versions/N/OSGI-INF/MANIFEST.MF resources. This allows the specification of different Import-Package and Require-Capability headers for the class implementation variations of a version. For example, a versioned variation can use some imported package or require some capability which is not needed by the variation in the base.
Bnd needs to be able to assemble the contents of a bundle and also calculate the main manifest and any necessary supplemental manifest. So Bnd must understand that the main jar and other Bundle-Classpath entries may be multi-release. If there is at least one multi-release container, the manifest calculation needs to take into account that the class variations may require a supplemental manifest in the main jar for the proper version. This would then cause the main jar to be multi-release even if it did not itself contains class variations.