Thanks for your analysis and explanation. I took the liberty to propose a PR for JDK-8353840: https://github.com/openjdk/jdk/pull/24499
I would really appreciate a review on this. ________________________________ From: Jorn Vernee <jorn.ver...@oracle.com> Sent: Monday, April 7, 2025 3:46 AM To: Danish Nawab <dna...@outlook.com>; core-libs-dev@openjdk.org <core-libs-dev@openjdk.org> Subject: Re: Usage feedback: jnativescan 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 [2] 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
