Usage feedback: jnativescan

[Jorn Vernee]

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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250407/6065f0ad/attachment-0001.htm>