8329581: Java launcher no longer prints a stack trace #18786

SoniaZaldana · 2024-04-15T18:25:02Z

Hi folks,

This PR aims to fix JDK-8329581.

I think the regression got introduced in JDK-8315458.

In the issue linked above, LauncherHelper#getMainType got removed to simplify launcher code.

Previously, we used getMainType to do the appropriate main method invocation in JavaMain. However, we currently attempt to do all types of main method invocations at the same time here.

Note how all of these invocations clear the exception reported with CHECK_EXCEPTION_FAIL.

Therefore, if a legitimate exception comes up during one of these invocations, it does not get reported.

I propose reintroducing LauncherHelper#getMainType but I'm looking forward to your suggestions.

Cheers,
Sonia

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issues

JDK-8329581: Java launcher no longer prints a stack trace (Bug - P3)
JDK-8329420: Java 22 (and 23) launcher calls default constructor although main() is static (Bug - P3)
JDK-8330864: No error message when ExceptionInInitializerError thrown in static initializer (Bug - P3)

Reviewers

Thomas Stuefe (@tstuefe - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/18786/head:pull/18786
$ git checkout pull/18786

Update a local copy of the PR:
$ git checkout pull/18786
$ git pull https://git.openjdk.org/jdk.git pull/18786/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 18786

View PR using the GUI difftool:
$ git pr show -t 18786

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/18786.diff

Webrev

Link to Webrev Comment

bridgekeeper · 2024-04-15T18:25:37Z

👋 Welcome back szaldana! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2024-04-15T18:26:45Z

@SoniaZaldana This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8329581: Java launcher no longer prints a stack trace
8329420: Java 22 (and 23) launcher calls default constructor although main() is static
8330864: No error message when ExceptionInInitializerError thrown in static initializer

Reviewed-by: stuefe

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 22 new commits pushed to the master branch:

789f704: 8322732: ForkJoinPool may underutilize cores in async mode
2c1b311: 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510
765ad0e: 8331947: Preview creates checkbox for JEP-less preview feature
8e903ee: 8331896: JFR: Improve check for JDK classes
3cbdf8d: 8333554: Parallel: Remove unused PSParallelCompact::is_in
3944e67: 8312132: Add tracking of multiple address spaces in NMT
d0052c0: 8333326: Linux Alpine build fails after 8302744
4369856: 8333130: MakeJAR2.sh uses hard-coded JDK version
1f09467: 8327368: javac crash when computing exhaustiveness checks
7dbd033: 8332499: Gtest codestrings.validate_vm fail on linux x64 when hsdis is present
... and 12 more: https://git.openjdk.org/jdk/compare/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@tstuefe, @mlchung) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk · 2024-04-15T18:27:09Z

@SoniaZaldana The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2024-04-15T21:15:08Z

Webrevs

mlchung · 2024-04-15T22:29:10Z

src/java.base/share/classes/sun/launcher/LauncherHelper.java

@@ -926,6 +948,8 @@ private static void validateMainMethod(Class<?> mainClass) {
            }
        }

+        setMainType(mainMethod);
+
        int mods = mainMethod.getModifiers();
        boolean isStatic = Modifier.isStatic(mods);


Can get the value for isStatic and noArgs from the main type.

mlchung · 2024-04-15T23:38:17Z

src/java.base/share/native/libjli/java.c

+    switch (mainType) {
+    case MAIN_WITH_ARGS:
+        res = invokeStaticMainWithArgs(env, mainClass, mainArgs);
+        break;
+    case MAIN_WITHOUT_ARGS:
+        res = invokeStaticMainWithoutArgs(env, mainClass);
+        break;
+    case MAIN_NONSTATIC:
+        res = invokeInstanceMainWithArgs(env, mainClass, mainArgs);
+        break;
+    case MAIN_NONSTATIC | MAIN_WITHOUT_ARGS:
+        res = invokeInstanceMainWithoutArgs(env, mainClass);
+        break;
+    }


Only one of invokeXXXMainYYYArgs is called. Looks like CHECK_EXCEPTION_FAIL and CHECK_EXCEPTION_NULL_FAIL are not needed and can use CHECK_EXCEPTION_LEAVE and CHECK_EXCEPTION_NULL_LEAVE instead?

wolfseifert · 2024-04-16T04:00:16Z

Isn't this already fixed by #18753?

AlanBateman · 2024-04-16T06:30:55Z

Yes, it would be good to try the changes in pull/18753 first.

tstuefe

Good find.

tstuefe · 2024-04-16T07:55:26Z

src/java.base/share/classes/sun/launcher/LauncherHelper.java

+     */
+    private static final int MAIN_WITHOUT_ARGS = 1;
+    private static final int MAIN_NONSTATIC = 2;
+    private static int mainType = 0;


Nit: transferring information from java to C in this way is usually done, AFAICS, by accessing static fields directly (GetStaticFieldID+GetStaticXXXField). There is also a helper function that wraps this, see JNU_GetStaticFieldByName. Not sure if you have that available in libjli though. There are many examples for both patterns.

I also would consider just declaring two booleans here, isStatic and hasArgs, which that would be a bit clearer to read instead of combining both into a single flag variable, and no need to keep flag values synced across java/C.

Thinking about this some more, would it not be possible to just use the mainMethod directly down in C?

The changes JEP 463 went through many iterations, it was a fine balance of avoiding too many transitions and upcalls, and at the same time, have something that can be maintained. There are several JBS issues on this issue now, probably because there just wasn't enough tests introduced with the JEP.

FWIW, just ran into this as well. I was trying to do System::loadLibrary and had no clue why I could load non-existent libraries. Turns out I couldn't :-) but the error was never reported back to me. Confusing.

tstuefe · 2024-04-16T08:23:06Z

Isn't this already fixed by #18753?

Yes, it would be good to try the changes in pull/18753 first.

I still like @SoniaZaldana 's variant better.

AFAIU, in the original variant, we choose the main method via MethodFinder.findMainMethod, but then down in JavaMain in C we just try to invoke all variants in succession (static,args->instance,args->static,noargs->instance,noargs). Does that no mean we ignore the decision of findMainMethod?

Apart from that, it means fewer exceptions are thrown when starting the JVM if we avoid calling methods we know don't work.

SoniaZaldana · 2024-04-16T14:26:35Z

@AlanBateman @wolfseifert Thanks for the comments!

Just wanted to note that I tried out #18753 and the issue is not resolved.

wolfseifert · 2024-04-17T12:52:54Z

Just tried to avoid unnecessary duplication of work.

wolfseifert · 2024-04-17T13:46:30Z

I tested now pull/18753 and pull/18786: both solve both issues JDK-8329420 and JDK-8329581

lahodaj · 2024-04-18T07:34:24Z

My personal comments here:

I am fine with a solution like this. In 18753, I wanted to avoid a change of dynamics between the Java helper and the native part. But if we can change that, it looks better. 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.) Or write a different test.
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; 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?)

SoniaZaldana · 2024-04-18T20:38:17Z

hi all, thanks for the comments! Happy to make the updates based on the feedback.

However, could someone please advice if we are proceeding with this PR or #18753?

As @lahodaj noted, theirs avoids changing the dynamics between the Java helper and native code, so I just want to make sure we are on the same page.

SoniaZaldana · 2024-04-18T20:41:05Z

@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.

mlchung · 2024-04-19T17:04:30Z

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.

… java launcher

SoniaZaldana · 2024-04-19T19:31:10Z

I made the updates based on feedback. Just a few things to note:

I included the test case from 8329420: Java 22 (and 23) launcher calls default constructor although main() is static #18753 and verified it passes with this PR.
Replacing CHECK_EXCEPTION_FAIL with CHECK_EXCEPTION_LEAVE looks a bit similar to my original proposed change. Calling CHECK_EXCEPTION_LEAVE directly in the JavaMain function causes the function to return early, whereas calling it inside the helpers (invokeStatic…) doesn’t quite have the same effect so I need to catch the result and then return.

Thanks!

mlchung · 2024-04-22T17:59:08Z

src/java.base/share/classes/sun/launcher/LauncherHelper.java

+    private static boolean isStatic = false;
+    private static boolean noArgs = false;


Suggested change

private static boolean isStatic = false;

private static boolean noArgs = false;

private static boolean isStaticMain = false;

private static boolean noArgMain = false;

mlchung · 2024-04-22T18:30:08Z

src/java.base/share/native/libjli/java.c

    jmethodID mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
                                  "([Ljava/lang/String;)V");
-    CHECK_EXCEPTION_FAIL();
+    CHECK_EXCEPTION_LEAVE(1);


Is this needed? invokeStaticMainWithArgs should only be called if the main method is validated as a static main with args.

A sanity check NULL_CHECK0(mainID) may be adequate (to use existing macro and so keeping the return value 0 to indicate error).

mlchung · 2024-04-22T18:32:16Z

src/java.base/share/native/libjli/java.c

 */
 int
-invokeStaticMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
+invokeStaticMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs,
+        JavaVM *vm, int ret) {


As CHECK_EXCEPTION_xxx_LEAVE assumes to be used within JavaMain and it changes the value of the local ret variable, it should call CHECK_EXCEPTION_RETURN_VALUE and NULL_CHECK_RETURN_VALUE instead.

JavaMain should call CHECK_EXCEPTION_LEAVE(1); after this method returns to print any exception and exit.

mlchung · 2024-04-22T18:49:05Z

src/java.base/share/native/libjli/java.c

-        LEAVE();
+
+
+    jclass helperClass = GetLauncherHelperClass(env);


Follow this file convention, declare all local variables at the beginning of this function.

mlchung · 2024-04-22T18:52:04Z

src/java.base/share/native/libjli/java.c

+    jfieldID isStaticField =
+        (*env)->GetStaticFieldID(env, helperClass, "isStatic", "Z");
+    jboolean isStatic =
+        (*env)->GetStaticBooleanField(env, helperClass, isStaticField);


Check exception. Local variable declared at the beginning of the function.

Suggested change

jfieldID isStaticField =

(*env)->GetStaticFieldID(env, helperClass, "isStatic", "Z");

jboolean isStatic =

(*env)->GetStaticBooleanField(env, helperClass, isStaticField);

isStaticMainField = (*env)->GetStaticFieldID(env, helperClass, "isStaticMain", "Z");

CHECK_EXCEPTION_NULL_LEAVE(isStaticMain);

isStaticMain = (*env)->GetStaticBooleanField(env, helperClass, isStaticMainField);

mlchung · 2024-04-22T18:52:54Z

src/java.base/share/native/libjli/java.c

+    jfieldID noArgsField =
+        (*env)->GetStaticFieldID(env, helperClass, "noArgs", "Z");
+    jboolean noArgs =
+        (*env)->GetStaticBooleanField(env, helperClass, noArgsField);


Suggested change

jfieldID noArgsField =

(*env)->GetStaticFieldID(env, helperClass, "noArgs", "Z");

jboolean noArgs =

(*env)->GetStaticBooleanField(env, helperClass, noArgsField);

noArgMainField = (*env)->GetStaticFieldID(env, helperClass, "noArgMain", "Z");

CHECK_EXCEPTION_NULL_LEAVE(noArgMain);

noArgMain = (*env)->GetStaticBooleanField(env, helperClass, noArgMainField);

mlchung · 2024-04-22T18:54:04Z

src/java.base/share/native/libjli/java.c

+            ret = invokeInstanceMainWithArgs(env, mainClass, mainArgs, vm, ret);
+       }
+    }
+


Add CHECK_EXCEPTION_LEAVE(1); to check any exception thrown when the main method is invoked.

mlchung · 2024-04-22T18:59:20Z

src/java.base/share/native/libjli/java.c

    jmethodID mainID = (*env)->GetStaticMethodID(env, mainClass, "main",
                                       "()V");
-    CHECK_EXCEPTION_FAIL();
+    CHECK_EXCEPTION_LEAVE(1);


Same comment as invokeStaticMainWithArgs.

Suggested change

CHECK_EXCEPTION_LEAVE(1);

NULL_CHECK0(mainID);

mlchung · 2024-04-22T19:03:06Z

src/java.base/share/native/libjli/java.c

 */
 int
-invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) {
+invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs,


int invokeInstanceMainWithArgs(JNIEnv *env, jclass mainClass, jobjectArray mainArgs) { jmethodID mainID = (*env)->GetMethodID(env, mainClass, "main", "([Ljava/lang/String;)V"); NULL_CHECK0(mainID); jmethodID constructor = (*env)->GetMethodID(env, mainClass, "<init>", "()V"); NULL_CHECK0(constructor); jobject mainObject = (*env)->NewObject(env, mainClass, constructor); CHECK_EXCEPTION_RETURN_VALUE(0); NULL_CHECK0(mainObject); (*env)->CallVoidMethod(env, mainObject, mainID, mainArgs); return 1; }

mlchung · 2024-04-22T19:03:49Z

src/java.base/share/native/libjli/java.c

 */
 int
-invokeInstanceMainWithoutArgs(JNIEnv *env, jclass mainClass) {
+invokeInstanceMainWithoutArgs(JNIEnv *env, jclass mainClass,


See the suggestion for invokeInstanceMainWithArgs

SoniaZaldana · 2024-04-23T18:21:30Z

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!

ecki · 2024-04-23T18:41:54Z

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.

I think such errors have a very high potential to confuse the hell out of the poor ops people looking for binary corruptions and stuff when it’s “only” a regular Java level error condition. So I think it should not talk about JNI in this case (even when the rest of the exception makes it obvious)

mlchung · 2024-04-23T18:47:15Z

I missed that NULL_CHECK0 prints that JNI error, sorry. We should avoid using it then. What do you think having a check macro to return 0 if exception occurred or the given object is null? No exception cleared as it will be described in JavaMain.

#define CHECK_EXCEPTION_NULL_FAIL(obj) \
    do { \
        if ((*env)->ExceptionOccurred(env)) { \
            return 0; \
        } else if (obj == NULL) { \
            return 0; \
        } \
    } while (JNI_FALSE)

AlanBateman · 2024-05-14T07:40:05Z

but it does not state explicitly that an exception is thrown on every error, or whether there are cases where the API can return NULL but not throw an exception, or vice versa.

So, I'd check for both. Or, if we think that both should not happen or happen together, assert that. (we can use the standard C assert in the JDK libraries, no?)

This same issue comes up periodically and maybe the JNI spec needs improvement to make it clearer that returning NULL means there is a pending exception/error. JNI would be very broken if it were to return a jclass or ID and also raise an exception, or return NULL rather than a jclass or ID when it succeeds.

As you say, it's not wrong to check both, just a bit strange as they can be just checks for NULL. At some point I think we need to do a round of cleanup here as these macros can mask other issues.

jaikiran · 2024-05-31T07:58:56Z

Hello Sonia, I happened to be working on something else and ended up hitting an issue where the java launch was failing with exit code 1 but was no longer printing the exception from the main application and realized that this PR hasn't been integrated.

I see Alan has suggested a change but I'm unsure if you plan to implement that in this PR or if that's something that's suggested for a subsequent cleanup. I think it would be good to have the review suggestions resolved soon and have this integrated.

jaikiran · 2024-05-31T08:27:28Z

/issue add JDK-8329420

openjdk · 2024-05-31T08:28:21Z

@jaikiran Only the author (@SoniaZaldana) is allowed to issue the /issue command.

SoniaZaldana · 2024-05-31T14:06:43Z

/issue add JDK-8329420

openjdk · 2024-05-31T14:07:24Z

@SoniaZaldana
Adding additional issue to issue list: 8329420: Java 22 (and 23) launcher calls default constructor although main() is static.

SoniaZaldana · 2024-05-31T14:11:19Z

/issue add JDK-8330864

openjdk · 2024-05-31T14:12:54Z

@SoniaZaldana
Adding additional issue to issue list: 8330864: No error message when ExceptionInInitializerError thrown in static initializer.

SoniaZaldana · 2024-05-31T14:34:16Z

Hi all,

I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc.

Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately.

If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.

cc: @jaikiran, @AlanBateman

AlanBateman · 2024-06-04T12:48:08Z

Hi all,

I think there's some consensus that we need some follow up cleanup issues for the JNI spec, renaming constants, fixing return codes, etc.

Seeing how that grows the scope of the issue quite a bit, I'd like to push this patch and track the other issues brought up separately.

If there are no objections about the current state, I'd like to integrate some time next week. Let me know your thoughts.

cc: @jaikiran, @AlanBateman

Okay. The follow-on issue can remove CHECK_EXCEPTION_NULL_FAIL introduced by this PR or replace it with something simple that just checks if the ID is null.

jaikiran · 2024-06-04T12:59:54Z

Hello Sonia @SoniaZaldana, so based on Alan's latest inputs, the next thing to do on this PR is to refresh the PR to merge it with the latest master branch changes and then run tier1, tier2 and tier3 tests to make sure they continue to pass and have this integrated soon.

I'll file follow up issue(s) and also trigger CI testing of this PR.

AlanBateman · 2024-06-04T13:07:06Z

I'll file follow up issue(s) and also trigger CI testing of this PR.

Thanks, the regressions fixed here are important to fix. It's unfortunate there the original changes weren't changes weren't caught by tests. There is a good test coverage added here but I think we'll need to see if there are other testing gaps.

tstuefe

Latest version is still good.

tstuefe · 2024-06-04T13:17:11Z

Hello Sonia @SoniaZaldana, so based on Alan's latest inputs, the next thing to do on this PR is to refresh the PR to merge it with the latest master branch changes and then run tier1, tier2 and tier3 tests to make sure they continue to pass and have this integrated soon.

Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3 you want to have tested?

AlanBateman · 2024-06-04T13:34:29Z

Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3 you want to have tested?

I think just prudent to run more tests when touching the launcher as it has options that aren't tested much in tier1. Shouldn't be an issue here but thinking of the splash screen tests (jdk_desktop test group), and tests for Java agents. Also jlink and jpackage can be useful when testing changes to the launcher.

jaikiran · 2024-06-05T01:59:50Z

@SoniaZaldana CI testing of this PR along with latest master commits passed without any failures. So you can now integrate this.

SoniaZaldana · 2024-06-05T13:06:06Z

@SoniaZaldana CI testing of this PR along with latest master commits passed without any failures. So you can now integrate this.

Thanks @jaikiran!

SoniaZaldana · 2024-06-05T13:06:11Z

/integrate

openjdk · 2024-06-05T13:08:16Z

@SoniaZaldana
Your change (at version 12fe416) is now ready to be sponsored by a Committer.

jaikiran · 2024-06-05T13:11:44Z

/sponsor

openjdk · 2024-06-05T13:12:32Z

Going to push as commit cbb6747.
Since your change was applied there have been 22 commits pushed to the master branch:

789f704: 8322732: ForkJoinPool may underutilize cores in async mode
2c1b311: 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510
765ad0e: 8331947: Preview creates checkbox for JEP-less preview feature
8e903ee: 8331896: JFR: Improve check for JDK classes
3cbdf8d: 8333554: Parallel: Remove unused PSParallelCompact::is_in
3944e67: 8312132: Add tracking of multiple address spaces in NMT
d0052c0: 8333326: Linux Alpine build fails after 8302744
4369856: 8333130: MakeJAR2.sh uses hard-coded JDK version
1f09467: 8327368: javac crash when computing exhaustiveness checks
7dbd033: 8332499: Gtest codestrings.validate_vm fail on linux x64 when hsdis is present
... and 12 more: https://git.openjdk.org/jdk/compare/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2...master

Your commit was automatically rebased without conflicts.

openjdk · 2024-06-05T13:12:47Z

@jaikiran @SoniaZaldana Pushed as commit cbb6747.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8329581: Java launcher no longer prints a stack trace

2ed5a93

openjdk bot added the core-libs core-libs-dev@openjdk.org label Apr 15, 2024

SoniaZaldana marked this pull request as ready for review April 15, 2024 21:11

openjdk bot added the rfr Pull request is ready for review label Apr 15, 2024

mlchung reviewed Apr 15, 2024

View reviewed changes

tstuefe reviewed Apr 16, 2024

View reviewed changes

SoniaZaldana added 3 commits April 19, 2024 15:28

Removing CHECK_EXCEPTION_FAIL in favour of CHECK_EXCEPTION_LEAVE

c56db44

Removing the need to call mainType method and adding static fields to…

72b7056

… java launcher

Adding test case

97a5f53

Fixing space formatting

79c7034

mlchung reviewed Apr 22, 2024

View reviewed changes

Changes based on feedback

6694223

Merge branch 'openjdk:master' into JDK-8329581

12fe416

tstuefe approved these changes Jun 4, 2024

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Jun 5, 2024

openjdk bot added the integrated Pull request has been integrated label Jun 5, 2024

openjdk bot closed this Jun 5, 2024

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Jun 5, 2024

jaikiran mentioned this pull request Jun 6, 2024

8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in java launcher #19576

Closed

3 tasks

		private static boolean isStatic = false;
		private static boolean noArgs = false;

8329581: Java launcher no longer prints a stack trace #18786

8329581: Java launcher no longer prints a stack trace #18786

Conversation

SoniaZaldana commented Apr 15, 2024 • edited by openjdk bot Loading

Progress

Issues

Reviewers

Reviewing

Webrev

bridgekeeper bot commented Apr 15, 2024

openjdk bot commented Apr 15, 2024 • edited Loading

openjdk bot commented Apr 15, 2024

mlbridge bot commented Apr 15, 2024 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wolfseifert commented Apr 16, 2024

AlanBateman commented Apr 16, 2024

tstuefe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlanBateman Apr 16, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tstuefe commented Apr 16, 2024

SoniaZaldana commented Apr 16, 2024

wolfseifert commented Apr 17, 2024

wolfseifert commented Apr 17, 2024

lahodaj commented Apr 18, 2024

SoniaZaldana commented Apr 18, 2024

SoniaZaldana commented Apr 18, 2024

mlchung commented Apr 19, 2024

SoniaZaldana commented Apr 19, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SoniaZaldana commented Apr 23, 2024

ecki commented Apr 23, 2024 • edited Loading

mlchung commented Apr 23, 2024

AlanBateman commented May 14, 2024 • edited Loading

jaikiran commented May 31, 2024 • edited Loading

jaikiran commented May 31, 2024

openjdk bot commented May 31, 2024

SoniaZaldana commented May 31, 2024

openjdk bot commented May 31, 2024

SoniaZaldana commented May 31, 2024

openjdk bot commented May 31, 2024

SoniaZaldana commented May 31, 2024

AlanBateman commented Jun 4, 2024

jaikiran commented Jun 4, 2024

AlanBateman commented Jun 4, 2024

tstuefe left a comment

Choose a reason for hiding this comment

tstuefe commented Jun 4, 2024

AlanBateman commented Jun 4, 2024

jaikiran commented Jun 5, 2024

SoniaZaldana commented Jun 5, 2024

SoniaZaldana commented Jun 5, 2024

openjdk bot commented Jun 5, 2024

jaikiran commented Jun 5, 2024

openjdk bot commented Jun 5, 2024

openjdk bot commented Jun 5, 2024

SoniaZaldana commented Apr 15, 2024 •

edited by openjdk bot

Loading

openjdk bot commented Apr 15, 2024 •

edited

Loading

mlbridge bot commented Apr 15, 2024 •

edited

Loading

AlanBateman Apr 16, 2024 •

edited

Loading

ecki commented Apr 23, 2024 •

edited

Loading

AlanBateman commented May 14, 2024 •

edited

Loading

jaikiran commented May 31, 2024 •

edited

Loading