RFR: 8329581: Java launcher no longer prints a stack trace

Sonia Zaldana Calles szaldana at openjdk.org
Tue Apr 23 18:24:30 UTC 2024


On Fri, 19 Apr 2024 17:04:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @lahodaj 
>> 
>>> I would suggest to take the test from 18753 though - doing a change like this without a test may lead to hard-to-find regressions in the future. (Note the current test should guard against both JDK-8329420 and JDK-8329581.)
>> 
>> Agreed. I’ll add the test case if this PR proceeds (see my comment above). 
>> 
>>> as Mandy points out, `LaucherHelper` already reads/has variables for "is-static" and "no-arguments" in `validateMainMethod`, so it should be possible to just use that values; 
>> 
>> Just to clarify, this would still mean converting “isStatic” and “noArgs” from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?
>> 
>>> also as Mandy points out, we can probably get rid of `CHECK_EXCEPTION_FAIL` and `CHECK_EXCEPTION_NULL_FAIL`, and use the `..._LEAVE` variants, no? (The `..._FAIL` variants where needed so that the launcher could continue with the next variant, but since we now only call the correct variant, we can just stop if something goes wrong?)
>> 
>> Agreed, I’ve updated that on my side of things.
>
>> Just to clarify, this would still mean converting “isStatic” and “noArgs” from local variables to fields so I am able to read them on the C side of things. Did I understand this correctly?
> 
> I'm okay with adding static boolean fields and read by the native code and the name can be explicit like `isStaticMain` and `mainWithNoArg`.

Hi @mlchung, thanks for the feedback! I’ve pushed the updates.

Just a question about ```NULL_CHECK0```. 

```NULL_CHECK0``` reports the error message and then the exception is described in ```CHECK_EXCEPTION_LEAVE```. This results in a stack trace that looks like this: 


Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.NoClassDefFoundError: DemoSonia$SomeDependency
	at DemoSonia.<clinit>(DemoSonia.java:3)
Caused by: java.lang.ClassNotFoundException: DemoSonia$SomeDependency
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)
	... 1 more



The JNI error message didn’t previously get reported before the regression was introduced, so I just wanted to make sure we were okay with this. 

Looking forward to your comments!

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

PR Comment: https://git.openjdk.org/jdk/pull/18786#issuecomment-2073092870


More information about the core-libs-dev mailing list