Why static_jli for java/javaw on Windows?
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Thu Sep 13 13:07:04 UTC 2018
On Windows, we compile two versions of libjli, one normal dynamic dll,
and one static library *). Then when we create our launchers, we link
with the normal, dynamic libjli for all launchers, except java.exe and
javaw.exe, which are linked with the static library.
The build system needs to do some elaborate dancing to support this odd
behavior, which affects code quality negatively. I would therefore like
to remove this special treatment of java.exe and javaw.exe.
I've done some extensive amount of code archeology to try and determine
where and how this was added. The only thing I can figure out is that it
was this way in the old build system, in the initial load of OpenJDK. In
jdk/make/java/main/java/Makefile, two comments might shed some light:
# Statically link java to avoid the dependency on msvcr71.dll.
# Statically link java to avoid the dependency on jli.dll.
Apparently, someone was trying to get rid of dll dependencies from
java.exe. Why that would be desirable it does not say. Neither why this
should not apply to all other launchers. (Perhaps there were not that
many in these days?)
Do anyone think this still seems relevant? Otherwise I'd like to get rid
of this hack, and link java and javaw just like all the other launchers.
*) Yeah, we do other funky stuff with libjli on other platforms as well.
But for now, I'm focusing on Windows.
More information about the core-libs-dev