RFR: 8347755: Support static library in jmod [v6]

[Jiangli Zhou]

On Thu, 17 Apr 2025 22:42:10 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> We agreed that to add a liblauncher to facilitate the `main` entry point. However, as I mentioned before, this is really a depends on situation and should be answered at link time. One obvious question is how do we deliver javaw(with WinMain) symbol for Windows?
> 
> Also all the tunable configuration at build time such as MAIN_CLASS and JAVA_ARGS for an executable? Or are we simply thinking of `java` here?

The default Java launcher `main.o` (and packaged as `liblauncher` static library) is produced by https://github.com/openjdk/jdk/blob/ad7c475fb1e23f583a33d58f0bd73ea0fb56740c/make/modules/java.base/Launcher.gmk#L39:


$(eval $(call SetupBuildLauncher, java, \
    ENABLE_ARG_FILES := true, \
    EXPAND_CLASSPATH_WILDCARDS := true, \
    EXTRA_RCFLAGS := $(JAVA_RCFLAGS), \
    VERSION_INFO_RESOURCE := $(JAVA_VERSION_INFO_RESOURCE), \
    OPTIMIZATION := HIGH, \
))


That should be used to link the launcher executable when jlink creates the final image, if no custom launcher is used.

With the https://github.com/openjdk/leyden/blob/hermetic-java-runtime/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/LinkHermeticImagePlugin.java prototype, we could pass additional linking flags to to form the complete native linking command (when integrating with the static .jmod support). With with that, I think we can pass the default `liblauncher.a` as part of the extra linking flags. Then, that may help simplify things for us by not having to include `liblauncher` in `java.base` static .jmod and not have to deal with optionally using the default `liblauncher` from the .jmod for linking. We could go with that. 

The default launcher and custom launcher would be handled similarly then, by passing via the extra linking flag.

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

PR Comment: https://git.openjdk.org/leyden/pull/46#issuecomment-2814220035