On Wed, 4 Sep 2024 23:28:10 GMT, Jiangli Zhou <jian...@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

Reply via email to