On Wed, 19 Feb 2025 06:54:50 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>> Jiangli Zhou has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. > > On a more general note, is it a goal to have the static JDK build run against > all these tests that are part of the JDK repo? Would that mean that a lot of > these will have to start using `@requires` to accomodate this? @jaikiran, thanks for taking a look! > Hello Jiangli, the change to introduce a `@requires` property for identifying > a static JDK looks OK to me. > > > @requires !jdk.static is added in > > test/hotspot/jtreg/runtime/modules/ModulesSymLink.java to skip running the > > test on static JDK. This test uses bin/jlink, which is not provided on > > static JDK. There are other tests that require tools in bin/. Those are not > > modified by the current PR to skip running on static JDK. Those can be done > > after the current change is fully discussed and reviewed/approved. > > This part however feels odd. Updating this (and other tests in future) to use > the `@requires !jdk.static` to identify the presence or absence of a specific > tool in the JDK installation doesn't seem right. Perhaps they should instead > rely on a tool-specific property (like maybe `@requires jdk.tool.jlink`)? Here is some additional context. I picked `ModulesSymLink.java` rather randomly from the hotspot tier1 test failures caused by missing `bin/` tools. I included it in the current change for testing the `@requires !jdk.static` property. There are about 30 test failures in hotspot tier1 due to missing `bin/` tools, those tests execute `bin/jlink`, `bin/jcmd`, `bin/jstat`, `bin/javac`, or etc at runtime. `ModulesSymLink.constructTestJDK()` specifically runs the `jlink` tool to create a test JDK during test execution. Since the `static-jdk` binary only provides a `bin/java` (and no other executables in `bin`), tests run any other tools at runtime in `bin/` fail. The current main issue with tools is that they require the shared libraries from JDK, for example `libjli.so`. Using a tool-specific property can be appropriate if we decide to support a specific set of tools for `static-jdk`, e.g. create a fully statically linked executable for supported tools, or including the tools required `. so` shared libraries in `static-jdk` image. Those details need to be discussed and worked out, we can add more fine grained properties when things are clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669442221
