RFR: 8339480: Build static-jdk image with a statically linked launcher

[Magnus Ihse Bursie]

On Wed, 4 Sep 2024 23:28:10 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> make/modules/java.desktop/lib/AwtLibraries.gmk line 176:
> 
>> 174: 
>> 175:   ifneq ($(ENABLE_HEADLESS_ONLY), true)
>> 176:     # We cannot link with both awt_headless and awt_xawt at the same time
> 
> Just a note on that. It's doable to link with both awt_headless and awt_xawt with some work. I did some quick experiments on that during the initial investigation for hermetic/static Java.

That would require quite some work then..! The two libraries are meant as exclusive complements to each other -- they both implement the same "entry points", but in different ways -- one with X11 support, and one without. For other reasons (outside of static launcher reasons) I'd like to see some refactoring in how this is implemented, but that is completely outside this discussion.

For the static launcher scenario, I can't even see the point of trying to include both? What would you accomplish by that? 

The entire point of having two libraries is that you want to be able to have full workstation capabilities, but then be dependent on the X11 libraries, or have limited capabilities, but skip the X11 dependency.

> src/java.base/unix/native/libjli/java_md.c line 300:
> 
>> 298:                            char jvmcfg[],  jint so_jvmcfg) {
>> 299:     /* Compute/set the name of the executable. This is needed for macOS. */
>> 300:     SetExecname(*pargv);
> 
> Why is `SetExecname()` needed for the static case?

Because of how macOS re-exec the launcher to reserve the main thread for GUI operations. Please check the rather extensive documentation elsewhere in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745171016
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1745172749