Using JNA bundled inside a Jigsaw Java module, class loading issue

[7118path]

JNA comes as a dependency in a project of ours, which is bundled and packaged with a JVM (using jlink and jpackage), so the code is enclosed as a module.

We are running into the following problem now:

The code needs to load the native dispatch library from the classpath using ithe method 'loadNativeDispatchLibraryFromClasspath' of 'Native.java'.o
Inside this method the library is loaded using a 'URLClassLoader'
To make the this work in packaged code (i.E. on OSX), our module needs to make this code avaliable from 'outside' the module via this line in the 'module-info.java':

opens com.sun.jna.darwin;

This works fine for OSX, but fails for other plattforms, if they contain a dash '-' in the package name of the native dispatch library.
A line like this results in an compile error, cause the dash is not allowed in package names:

opens com.sun.jna.win32-x86;

Question now is: Are there plans to move the code of JNA towards modularization? Then maybe this issue could be solved using the 'getResourceAsStream' method of the 'Module' class.
Or another (more hacky) way would be to rename the packages, so they do not contain any more dashes.

Any feedback regarding this issue yould be great. TIA!

[matthiasblaesing]

Please create a minimal sample that reproduces the problem, preferable as a maven project, so that it can be investigated. The project should not be bound to mac OS, as I won't be able to access that platform.

For the assumption, that an URL classloader is used to load the class, that is not correct. It is the thread context class loader that is used (or if that is null, the class loader, that loaded Native.class). In any case, why do you need to access this from outside the JNA module? The loading code is in the module and so there is no reason to break into it.

Towards modularization: There are no current plans. JNA comes with an Automatic-Module-Name in the manifest. The target platforms are still 6-X and the release JDK ist required to be JDK 8 (else ByteBuffer changes from JDK 9 are picked up and make the package incompatible).

In general: This does not look like an issue, so according to the issue template, this should be discussed on the google group and not here.

[7118path]

Thanks for your quick response. We do not yet understand, why this problem does only occur on OSX, and we are fully aware that this is a feature request, not a bug. Just to clarify the problem a little bit more:

The class loader seems to use 'getRessource' for loading the dispatcher lib. As stated here the package of the resource loaded (the dispatcher lib) must be opened, even if the loading call comes from within the module. We address this with the 'open' statement, which fails for packages with dash in the name.

If there are plans of supporting Java 9 and above in the future, we would like to know how this issue should be addressed. If really needed we can also discuss this at the google group. Thank you.

[matthiasblaesing]

I now did, what I asked you to do: I created a runnable sample:

https://github.com/matthiasblaesing/JNA-Demos/tree/master/JNA-JPMS-Jigsaw

The sample shows, that JNA works with JPMS/Jigsaw. So your claim, that Java 9 and above is unsupported is incorrect. Please see what you get when you run this sample.

You claim:

As stated here the package of the resource loaded (the dispatcher lib) must be opened, even if the loading call comes from within the module. We address this with the 'open' statement, which fails for packages with dash in the name.

This is not the full information - from the documentation of Module#getResourceAsInputStream:

A resource in a named module may be encapsulated so that it cannot be located by code in other modules. Whether a resource can be located or not is determined as follows:

• If the resource name ends with ".class" then it is not encapsulated.
• A package name is derived from the resource name. If the package name is a package in the module then the resource can only be located by the caller of this method when the package is open to at least the caller's module. If the resource is not in a package in the module then the resource is not encapsulated.

The package name in our case is not a package in the module, so it will not be encapsulated.

This is the reason that I explicitly asked for a sample, because then could already determine what is necessary to reproduce your issue.

[7118path]

Thank you very much for the example code. I did not want to claim that JNA cannot be used with Jigsaw and Java 9 and above. Sorry if it sounded this way.
As an endresult we create an application created with jpackage, which needs to have all it's modules bundled by jlink before running jpackage on it.
Jlink is only able to work with 'explicit' named modules in contrast to automatic modules as in the example. Because JNA (and other dependecies) are not available as explicit named modules,
we bundle them into a module by ourself and after that we observer that the rules regarding resource loading as described in the javadoc of Module and Classloader come into effect. The only odd thing is that we only face this problem with the OSX bundle, but that may be due to the exeprimental nature of JDK 14 and jpackage.
I will try to modify the example to build a package that way, so that the problem occurs.

[matthiasblaesing]

Just a gut feeling: You did not put code (classes) into the package com.sun.jna.darwin? As stated in the docs, once a directory is considered a package, it will be encapsulated.

[7118path]

Thanks for the hint. I have checked the jar we build before packaging and there is nothing to be found in com.sun.jna.darwin except the libjnidispatch.jnilib.

[7118path]

After playing around a little bit with your example, It seems like our issue is problably due to usage of a 4.5.x version of JNA, which has no module name in the manifest.
We will try to patch our dependencies using JNA to get them using 5.x and then bundle JNA as a module itself. Thank you very much for your explanations and the example code. I will close the issue and reopen only if needed. Best Regards!