On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab <d...@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.na...@sixt.com> Committer: Chen Liang <li...@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
