Hello,
I had a look here, and can reproduce the error.
jnativescan does have handling for Multi-Release jars. By default it
uses the current JDK version, which in your case would be 24. An exact
version can be specified using --release. The issue in this case is that
the error originates from the class file
reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException,
which does not have a class file entry in the META-INF/versions
directory. There is one for the enclosing class
reactor.core.publisher.CallSiteSupplierFactory, but not for this nested
class. jnativescan doesn't try to determine whether a class file is
used, it just scans all the class files in the jar file that belong to a
particular runtime version, so in this case, it doesn't see that the
TracingException class is not actually being used.
I think your idea of emitting a warning instead of an error is probably
the right one. We won't be able to determine whether a method being
referenced is restricted or not, since you need the class file to be
able to look at the annotations, but if the class can not be loaded on
the particular runtime version, then even if the method was restricted,
it could never be called any way.
Thank you for submitting this useful piece of feedback! I've filed:
https://bugs.openjdk.org/browse/JDK-8353840
Jorn
On 4-4-2025 18:58, Danish Nawab wrote:
|jnativescan| terminates when ran on a JAR with a missing class.
Example:
```
jnativescan --class-path reactor-core-3.7.4.jar
ERROR: Error while processing method:
reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
```
(above jar downloaded from [1])
The offending class seems to refer to a now unavailable
|sun.misc.JavaLangAccess| but still handles this error scenario
silently [2]
Because |jnativescan| terminates early, I can't say whether or not
this library uses native/restricted features. Perhaps it would be
better if instead of terminating, |jnativescan| continued the analysis
after warning about the missing class.
Also, the above JAR seems to be a Multi-Release Jar, where the Java
11+ version of the code does not even refer sun.misc.JavaLangAccess [3].
Should |jnativescan| have special handling for Multi-Release JARs by
analysing the version that would be applicable for the current JDK?
Versions:
```
java --version
openjdk 24 2025-03-18
OpenJDK Runtime Environment (build 24+36-3646)
OpenJDK 64-Bit Server VM (build 24+36-3646, mixed mode, sharing)
jnativescan --version
24
```
Overall, |jnativescan| is extremely helpful in finding the
dependencies using native/restricted features.
[1]
https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.7.4/reactor-core-3.7.4.jar
<https://repo1.maven.org/maven2/io/projectreactor/reactor-core/3.7.4/reactor-core-3.7.4.jar>
[2]
https://github.com/reactor/reactor-core/blob/7dee739/reactor-core/src/main/java/reactor/core/publisher/CallSiteSupplierFactory.java#L56-L64
<https://github.com/reactor/reactor-core/blob/7dee739/reactor-core/src/main/java/reactor/core/publisher/CallSiteSupplierFactory.java#L56-L64>
[3]
https://github.com/reactor/reactor-core/blob/0b93178/reactor-core/src/main/java11/reactor/core/publisher/CallSiteSupplierFactory.java
<https://github.com/reactor/reactor-core/blob/0b93178/reactor-core/src/main/java11/reactor/core/publisher/CallSiteSupplierFactory.java>
