RFC: 8229469 JEP 386: Alpine Linux/x64 Port

Aleksei Voitylov aleksei.voitylov at bell-sw.com
Fri Sep 4 20:55:41 UTC 2020


Alan,

here is a simpler version which, for the two tests in question, refers
to a local helper class with a native method:

http://cr.openjdk.java.net/~avoitylov/webrev.8247589.07/

If there is a preference to avoid JNI, there is yet another alternative:
split the two launcher tests in question into tests  with @requires
vm.musl | os.family = "aix" and with @requires !vm.musl & os.family !=
"aix".

-Aleksei

On 04/09/2020 15:51, Aleksei Voitylov wrote:
> Alan,
>
> in this case I'm leaning towards a new class jdk.test.lib.LibcHelper
> with a native implementation which calls (*env)->NewStringUTF(env,
> libc), which will be used by the tests which require it. Otherwise we'd
> have to specify nativepath for all tests which use
> jdk.test.lib.Platform. What do you think?
>
> -Aleksei
>
> On 04/09/2020 12:08, Alan Bateman wrote:
>> On 04/09/2020 10:00, Alan Bateman wrote:
>>> On 04/09/2020 08:55, Aleksei Voitylov wrote:
>>>> :
>>>> Tests tools/launcher/Test7029048.java and
>>>> tools/launcher/ExecutionEnvironment.java need to change behavior on
>>>> systems that alter LD_LIBRARY_PATH (AIX and musl). The alternative we
>>>> first considered was to detect the libc of the OS with ldd in the test
>>>> and avoid WhiteBox dependency. This approach has a significant
>>>> drawback:
>>>> some distributions bundle glibc and OpenJDK and launch it on a
>>>> musl-based Linux OS, so we really need to detect the libc the JDK was
>>>> compiled for, not the default libc present in the OS. To avoid such
>>>> problems all together it was decided to detect the libc flavor the JDK
>>>> was compiled for through WhiteBox.
>>>>
>>> I really dislike the changes to the launcher tests and I don't think
>>> the WB API is the right place for this. I think we need to find
>>> something cleaner and maybe expose it as a method on
>>> jdk.test.lib.Platform.
>>>
>> or alternatively, a new class in jdk.test.lib that gives provide
>> methods to introspect the runtime, whatever is simplest and doesn't
>> depend on the WB API as it's independent of HotSpot.
>>
>> -Alan



More information about the core-libs-dev mailing list