-
-
Notifications
You must be signed in to change notification settings - Fork 302
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 the Bnd will include module-info.class in the root of the bundle in the EE calculation when it really should not when the all other classes are Java 8 or lower.
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
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 its manifest. 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 any Bundle-Classpath.)