On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> In the static JDK image, a single humongous java executable is generated, and > no other launcher, such as javac. This makes it impossible to run our jtreg > tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial > launchers, which are thin wrappers that execute the main java binary, with > the proper arguments. This will result in the same behavior as the normal > dynamic launchers, only that we will need to take the detour of launching > another process instead of calling directly into the JLI library. A bit of discussion/rationale for this PR: * I did some preparation of the main launcher in 1d6c2ea66918667c2e9ef7619565cb3676a352d2. The old launcher code had a lot of weird stuff in `define.h` (which was not just defines, as the name implies). I simplified this and inlined it directly into main.c. I also renamed variables prefixed `const_`, because most of them will not be that after this PR, and it did not seem to bring much value to point this out in the name. * Any changes in main.c apart from these are within `#ifdef STATIC_BUILD` only, and should not affect the normal launcher. * The main launcher need some additional information to be able to launch any tool except the main "java" itself. Normally this is "hard-coded" into different builds of main.c by the use of compiler defines passed by the build. The approach I used for the static launcher is to pass this information as special system properties, with a name starting with `javaLauncher`. This will be treated as normal system properties by the launcher, but the additional code activated in the static build of the launcher will also interpret these values, and set the variables corresponding to how they would have been hardcoded in the dynamic launcher. * This could have been achieved by using shell script/bat file relaunchers instead. However, that seemed more risky, since it would change the launchers from native binaries to text files. On Windows, for instance, other programs might look for "javac.exe" and not consider "javac.bat" to be acceptable. * Finally, a commonly asked question when I developed this has been: "Could you not just symlink the java binary with different names, and then dispatch it depending on how it was called?". This is a common and clever technique, but it is not suitable here. First, it will not work on Windows. Secondly, it would require us to stuff all knowledge of all launchers into the main java binary. This solution, in contrast, distributes this knowledge out to every individual tool, making it possible to add new tools without modifying the main static binary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-2772911175
