On Wed, 30 Oct 2024 07:22:42 GMT, Jaikiran Pai <j...@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
