On Fri, 10 Apr 2026 08:43:24 GMT, Severin Gehwolf <[email protected]> wrote:
>> I meant the latter, the problem we observed with `cat props >> >> conf/security/java.security` is while linking a jmod-less image. The SHA-512 >> checksum of the original `conf/security/java.security` file is stored in the >> jimage file (`lib/modules`). So if we modify `conf/security/java.security` >> and run `jlink` (in a jmod-less JDK), we get `Error: >> .../conf/security/java.security has been modified`. > >> I meant the latter, the problem we observed with `cat props >> >> conf/security/java.security` is while linking a jmod-less image. The SHA-512 >> checksum of the original `conf/security/java.security` file is stored in the >> jimage file (`lib/modules`). So if we modify `conf/security/java.security` >> and run `jlink` (in a jmod-less JDK), we get `Error: >> .../conf/security/java.security has been modified`. > > Right. Note that there is also a concept of "upgradable files" and > `java.security` could be considered upgradable just like `cacerts` or > `tzdata`. See: https://bugs.openjdk.org/browse/JDK-8353185. Both would work, > but I tend to think the jlink plugin would be better suited for this. Just on the ">>" discussion. I think the downside is that the resulting java.security may have duplicate keys with different values. The files in $JAVA_HOME/conf are user editable so if someone were to edit java.security then they could easily change the value of the first key and the change would not be effective. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3065299126
