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 mailing list