bnd icon indicating copy to clipboard operation
bnd copied to clipboard

osgi.ee computation needs to take modules-info.class into account

Open laeubi opened this issue 3 years ago • 2 comments

I noticed when working on the multirelease support that when I have a jar file analyzed that is all java-8 with the exception of the modules-info.class then BND generates the following header

Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"

while I would expect it to be:

Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9))"

laeubi avatar Jul 27 '22 12:07 laeubi

There can be multiple module-info.class files in a multi-release jar. Meanwhile all the code in the jar is compiled to Java 8 which is still a perfectly valid jar and very much a valid use case.

What you might want is a META-INF/versions/x/MANIFEST.MF for each multi-release version which contains a Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=X))" targeting that exact version and ensure that the framework handles/merges Require-Capability.

rotty3000 avatar Aug 02 '22 16:08 rotty3000

There can be multiple module-info.class files in a multi-release jar. Meanwhile all the code in the jar is compiled to Java 8 which is still a perfectly valid jar and very much a valid use case.

This is independent of multi-release, you can try that out with a plan jar where all classes are compiled with java 8 and the module-info.class is compiled with java 9

What you might want is a META-INF/versions/x/MANIFEST.MF for each multi-release version which contains a Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=X))" targeting that exact version and ensure that the framework handles/merges Require-Capability.

Yes see https://github.com/bndtools/bnd/pull/5331, still BND then generates for the version/9 part Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"

laeubi avatar Aug 02 '22 16:08 laeubi

osgi.ee computation must not take into account module-info.class. OSGi (consumer of osgi.ee) and JPMS (consumer of module-info.class) are mutually exclusive. While a jar can be built which is both a proper JPMS module and a proper OSGi bundle, the jar cannot be simultaneously loaded by both OSGi and JPMS.

In the OSGi case, module-info.class is ignored by OSGi bundle class loaders. So the class version of module-info.class is not material to OSGi.

In the JPMS case, osgi.ee is ignored by JPMS. So the osgi.ee version is not material to JPMS.

bjhargrave avatar Sep 06 '22 17:09 bjhargrave