RFR: 8343040: Clean up references to JRE in the launcher code [v3]

[Jaikiran Pai]

On Wed, 30 Oct 2024 07:22:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up references to "JRE" from the launcher's code?
>> 
>> No functional changes have been introduced in this change.
>> 
>> No new tests have been introduced and existing tests in tier1, tier2 and tier3 continue to pass in our CI against Linux, macosx and Windows.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix incorrect error macro usage

> GitHub UI doesn't let me add this comment inline, so adding this here. There's this `if` block (only) in the `src/java.base/macosx/native/libjli/java_md_macosx.m`:
> 
> ```c
> /* Does the app ship a private JRE in <apphome>/jre directory? */
> JLI_Snprintf(libjava, sizeof(libjava), "%s/jre/lib/" JAVA_DLL, path);
> if (access(libjava, F_OK) == 0) {
>     JLI_StrCat(path, "/jre");
>     JLI_TraceLauncher("JRE path is %s\n", path);
>     return JNI_TRUE;
> }
> ```
> 
> I have let this stay and haven't changed it, since any changes here would be functional. I think we will have to look into this separately and decide if we should continue supporting this. What this is doing here is that it's trying to find `jre/lib/libjava.dylib` under the current running process' launched "home" path and if it finds one, then it considers the process' launched "home" path as the JDK installation root. It's not clear why we do this only in the macosx implementation (I will check the history).


This appears to be a leftover from the changes in https://bugs.openjdk.org/browse/JDK-8329862. I have created https://bugs.openjdk.org/browse/JDK-8343293 to remove this code from the macosx variant.

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

PR Comment: https://git.openjdk.org/jdk/pull/21704#issuecomment-2447036049