On Fri, 10 Apr 2026 15:45:21 GMT, Alan Bateman <[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`. >> >> 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. > 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`. Why don't you get the error in a jmod JDK? Just trying to understand the distinction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3066415027
