> ## 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 ...
Danish Nawab has updated the pull request incrementally with one additional commit since the last revision: 8353840: improve error logging ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24499/files - new: https://git.openjdk.org/jdk/pull/24499/files/e658c466..3aaef9d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24499&range=00-01 Stats: 48 lines in 4 files changed: 20 ins; 2 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/24499.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24499/head:pull/24499 PR: https://git.openjdk.org/jdk/pull/24499
