On Wed, 19 Feb 2025 07:33:02 GMT, Alan Bateman <al...@openjdk.org> wrote:
> > 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`)? > > The property will be useful to select the tests that can or cannot be > selected by jtreg when the JDK under test is static image. There are a number > of tests that depend on layout or specific files in the modular run-time > image so they will need to skipped when the JDK is a static image. So nothing > to do with whether specific tools are present or not. The specific test > updated here is a bit strange because lib/modules should never be a sym link > in the first place and motivation for that is probably a different discussion. The discussion here made me realize that for the specific ModulesSymLink.java, there are multiple layered issues, including: - No `jlink` tool in `static-jdk` when running on static JDK. This is currently observable using the `static-jdk`. - No separate `lib/modules` file (and other JDK resource files) if we build a single hermetic Java image for the test. Those JDK files will be built into the single hermetic executable image for runtime access. It would more practical to develop new tests specifically for hermetic image, and not try to run all existing jtreg tests using hermetic package and filtering using @requires property. +1 on @AlanBateman's comment, the second layer is separate discussion which can involve java.home. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23528#issuecomment-2669758714
