Integrated: 8353840: JNativeScan should not abort for missing classes

[Danish Nawab]

On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab <duke at openjdk.org> wrote:

> ## Description
> 
> https://bugs.openjdk.org/browse/JDK-8353840 
> 
> ### Existing behavior
> Log the error message and terminate in case of missing system class
> 
> 
> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?"
> 
> ERROR: Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
> CAUSED BY: System class can not be found: sun.misc.JavaLangAccess
> Exit code: 1
> 
> 
> ### New behavior
> Still log the error message about the missing system class, but continue the analysis
> 
> 
> $ build/macosx-aarch64-server-release/jdk/bin/jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit code: $?" 
> 
>   <no restricted methods>
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String: System class can not be found: sun.misc.JavaLangAccess
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::<clinit>()void: System class can not be found: sun.misc.SharedSecrets
> Error while processing method: reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory::<clinit>()void: System class can not be found: sun.misc.SharedSecrets
> Exit code: 0
> 
> 
> ## Design choices
> 
> Propagate `err` all the way to `NativeMethodFinder` which can log the error to it, but continue with the analysis
> 
> ### Alternatives considered
> 
> - Instead of propagating `err` downstream, adapt the outer try-catch in `com.sun.tools.jnativescan.Main#run`.
>     - Con: This would require complicated error recovery synchronization between Main and `JNativeScanTask` to resume the scanning after the exception 
> - Instead of adapting the catch block in `com.sun.tools.jnativescan.NativeMethodFinder#findAll`, don't even surface the exception from `com.sun.tools.jnativescan.ClassResolver.SystemModuleClassResolver#lookup` rather log it right in `ClassResolver`
>     - Con: We don't have access to `MethodRef`/`MethodModel` in ClassResolver#lookup which will make the error message less detailed/useful
> 
> ### stdout vs stderr 
> 
> One could argue that since this is a non-terminal error, perhaps it should be logged to stdout. However, my thinking was that while it may be non-terminal, it is still an "error", and thus should be logged to stderr. I am happy to revisit this decision, if needed.
> 
> ## Testing
> 
> The existing test `TestMissingSystemClass#testSingleJarClassPath` has ...

This pull request has now been integrated.

Changeset: 5f2a604b
Author:    Danish Nawab <danish.nawab at sixt.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f2a604b633c0cd24f897f828a7c928c3d2b651c
Stats:     54 lines in 5 files changed: 25 ins; 2 del; 27 mod

8353840: JNativeScan should not abort for missing classes

Reviewed-by: jvernee, liach

-------------

PR: https://git.openjdk.org/jdk/pull/24499