RFC: 8229469 JEP 386: Alpine Linux/x64 Port

Alan Bateman Alan.Bateman at oracle.com
Sun Sep 6 08:13:24 UTC 2020


On 04/09/2020 21:55, Aleksei Voitylov wrote:
> 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".
>
The download side of using JNI in these tests is that it complicates the 
setup a bit for those that run jtreg directly and/or just build the JDK 
and not the test libraries. You could reduce this burden a bit by 
limiting the load library/isMusl check to Linux only, meaning isMusl 
would not be called on other platforms.

The alternative you suggest above might indeed be better. I assume you 
don't mean splitting the tests but rather just adding a second @test 
description so that the vm.musl case runs the test with a system 
property that allows the test know the expected load library path behavior.

The updated comment in java_md.c in this looks good. A minor comment on 
Platform.isBusybox is Files.isSymbolicLink returning true implies that 
the link exists so no need to check for exists too. Also the 
if-then-else style for the new class in ProcessBuilder/Basic.java is 
inconsistent with the rest of the test so it stands out.

Given the repo transition this weekend then I assume you'll create a PR 
for the final review at least. Also I see JEP 386 hasn't been targeted 
yet but I assume Boris, as owner, will propose-to-target and wait for it 
to be targeted before it is integrated.

-Alan


More information about the core-libs-dev mailing list