Hermetic Java project meeting

[Magnus Ihse Bursie]

This is my summary of what was said in today's meeting:

* Jiangli reported that her team had done extensive testing and not seen 
any problems, both with just the static launcher as generated by the 
leyden branch, and with bundled user applications using the One Jar (?) 
tool. They tested JDK tier 1, and an suite of Google's internal tests. 
When testing JTReg tests with native libraries, these were dynamically 
loaded.

* Alan asked about Hotspot JTReg tests that launched "java". Jiangli 
reported that they had not seen any problems, but my understanding was 
that there was some confusion if any such tests were actually run. I 
think this is something that will need further attention, but if someone 
said they would look into it, I missed it.

  * Jiangli will get numbers on how much time is added to the GHA 
testing if we add building and linking of static libraries, without 
fixing so we can compile to a single set of object files.

* We did not fully come to a conclusion if compiling on a single set of 
object files for static and dynamic linking was a hard requirement or 
not, but at a minimum it is a desirable goal. (My personal opinion is 
that is a hard requirement if the GHA build times are seriously affected 
otherwise.)

There are basically two problems prohibiting single object file 
compilation:

1) using dynamic checks instead of #ifdefs for code that differs between 
static and dynamic.

2) Handling the difference between JNI_OnLoad (as required for dynamic 
libraries) and JNI_OnLoad_<libname> (as required for static libraries).

* The leyden branch has basically solved both these problems. The first 
one could more or less be integrated already (given perhaps some 
discussion on exactly *how* the JDK should discover in runtime if it is 
static or dynamic), but the latter requires a spec change to be integrated.

* I think everyone agreed that moving on with a spec change was a good 
idea, regardless of if this is blocker or not, but I don't recall that 
there were any concrete next steps decided. Ron and Alan said that we do 
spec changes all the time so it will not add as much bureaucracy as one 
might fear.

* Regarding which native libraries to include, I think we agreed on the 
following:
   - Static linking will only support headless-only builds (in which the 
build system excludes the AWT library that does "headful" stuff -- 
otherwise there would be duplicate symbols)
   - As a first delivery, the build system will just create a static 
version of the "java" launcher (not jar, javac, etc). This will include 
all native libraries from all modules that are included in the build.
   - Going forward, the correct solution is to make jlink create a 
launcher that includes just the native libraries from the modules that 
is included in the jlink command. This will require jlink to understand 
how to call the native linker.
   - Somewhere in there we probably also needs to have jlink know about 
headless-only vs normal (headless or "headful" determined on runtime), 
so it can create a java.desktop output that includes only the headless 
library.

* Magnus reported that the refactoring and fixing of technical debt that 
was required for doing static builds properly has just been finished, 
and that his attention is now turning into creating a properly 
integrated system for generating static builds alongside dynamic builds.

* Jiangli and Magnus will work outside the meeting to resolve the build 
issues Magnus faced with the hermetic java branch in the Leyden repo.

* Just before the meeting unfortunately had to be aborted, Jiangli 
mentioned that they had discovered issues with some JDK native libraries 
when using objcopy to localize all non-visible symbols. It was at the 
time of writing not clear what those issues were. Jiangli will report 
back with what they found. (And while I had not time to mention it on 
the meeting, I will also look into this.)

/Magnus