microstream icon indicating copy to clipboard operation
microstream copied to clipboard

Make (OSGi) dependency to jdk.internal.misc optional

Open Sandared opened this issue 2 years ago • 1 comments

Is your feature request related to a problem? Please describe.

Currently when I try to use Microstream 06.01.00-MS-GA in an OSGi runtime I receive resolver errors, complaining about 'one.microstream.base' missing requirement 'jdk.internal.misc'. This probably stems from current enhancements in the bnd Tool which is used internally by the maven bundle plugin to generate the manifest. (They now seem to search for Class.forName() statements and the generate Import-Package declarations for it)

Describe the solution you'd like

As I understand it from looking at your code you only use this dependency here: https://github.com/microstream-one/microstream/blob/ddc87fda12161dc51636a8b35c868de6cc90bfb8/base/src/main/java/one/microstream/memory/sun/JdkInternals.java in order to work around some limitations with records in Java >= 16. Therefore I would suggest to make this Import explicitly optional, as it is only needed in the combination OSGi runtime + Java >= 16. This could be easily achieved by changing your maven-bundle-plugin configuration to

<configuration>
  <instructions>
	  <Export-Package>one.microstream*;-split-package:=merge-first</Export-Package>
	  <Import-Package>
                  jdk.internal.misc*;resolution:=optional,
                  *
          </Import-Package>
	  <DynamicImport-Package>*</DynamicImport-Package>
  </instructions>
</configuration>

Describe alternatives you've considered

I considered to hardcode my OSGi runtime to export this package by default, but would rather prefer to adapt the library than my runtime

Additional context


Sandared avatar Mar 15 '22 17:03 Sandared

In fact, it would be even better to apply different configurations to different submodules of microstream. I was considering to do it myself, but reckognized that I have not enough knowledge about your code :/

What's the problem with the current configuration of maven-bundle-plugin?

Currently the configuration is defined in the root pom, which means, each submodule will be processed accordingly with the same config. However the statements

<Import-Package>
     jdk.internal.misc*;resolution:=optional,
     *
</Import-Package>
<DynamicImport-Package>*</DynamicImport-Package>

are probably only sensible in very few submodules.

<ImportPackage> jdk.internal.misc*;resolution:=optional,*<Import-Package> for example is (as far as I cen tell) only sensible for the base submodule, as it is the only submodule where there is code like this: Class.forName("jdk.internal.misc.SomeClass"), which actually leads bnd to generating this Import Statement. All other bundles can have <Import-Package>*</Import-Package>

The <DynamicImport-Package>*</DynamicImport-Package> is a little bit trickier and also the reason why I don't think I could provide a PR in a sensible amount of time. This directive tells the OSGi Framework effecitvely "ignore your usual OSGi classloading for this bundle and scann all available bundles for the classes that this bundle tries to load". This directive usually is used for stuff like ORM libraries, where you do not know up front, which classes will be loaded by the library at runtime. The same case probably applies to microstream, but I assume not in all submodules. So this directive is only needed in those submodules, that do any sort of dynamic classloading at runtime for arbitrary classes that are usually provided by the user. Whenever possible this directive should ba as precise as possible, e.g., if you know that your bundle will only dynamically load classes from the package foo.bar, then the directive should be looking like this: <DynamicImport-Package>foo.bar*</DynamicImport-Package>

I hobe this helps with this issue :)

Sandared avatar Mar 18 '22 06:03 Sandared