On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:

>> This patch contains a set of changes to improve static builds. They will 
>> pave the way for implementing a full static-only java launcher. The changes 
>> here will:
>> 
>> 1) Make sure non-exported symbols are made local in the static libraries. 
>> This means that the risk of symbol conflict is the same for static libraries 
>> as for dynamic libraries (i.e. in practice zero, as long as a consistent 
>> naming scheme is used for exported functions).
>> 
>> 2) Remove the work-arounds to exclude duplicated symbols.
>> 
>> 3) Fix some code in hotspot and the JDK libraries that did not work properly 
>> with a static java launcher.
>> 
>> The latter fixes are copied from or inspired by the work done by 
>> @jianglizhou and her team as part of the Project Leyden [Hermetic 
>> Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Add dummy implementation of os::lookup_function for Windows

The changes to the launcher look okay. The move from `ifdef STATIC_BUILD` to 
`JLI_IsStaticallyLinked` is quite nice.

Having libjdwp link to libjvm was a surprise but I think okay.

I think it would be useful to provide a brief summary on the when/where the 
static builds are tested to ensure that the changes don't bit rot. I realise we 
already have static builds but it isn't obvious where this is tested.

src/hotspot/share/runtime/linkType.cpp line 36:

> 34:   return JNI_TRUE;
> 35: #else
> 36:   return JNI_FALSE;

bool != jboolean, I assume you don't want that.

The naming is a bit unusual, a function that returns a boolean is usually name 
is_XXX, but maybe there is reason for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/19478#issuecomment-2180635747
PR Review Comment: https://git.openjdk.org/jdk/pull/19478#discussion_r1647480992

Reply via email to