On Thu, 9 Apr 2026 16:20:17 GMT, Sean Mullan <[email protected]> wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SecurityPropertiesPlugin.java >> line 89: >> >>> 87: throw new IllegalArgumentException( >>> 88: "the include property is not supported"); >>> 89: } >> >> Why is this being treated specially? It makes the use-cases of using this >> `jlink` plugin more limited to editing the file in place (or using some >> post-processor). It would break some of the use cases we have with system >> crypto policies where this plugin would come in handy: >> >> Consider this use case: >> Take a generic JDK build that is about to being used to integrate with >> system crypto policies (see >> [JDK-8319332](https://bugs.openjdk.org/browse/JDK-8319332)) on some systems. >> The generic JDK build is also being used elsewhere where this isn't being >> done. The system policies are maintained by the OS and live in >> `/etc/crypto-policies/back-ends/java.config`, say. A custom `jlink` >> invocation including all modules with `--security-properties extra` could >> achieve this when `extra` contained >> `include=/etc/crypto-policies/back-ends/java.config`. The benefit of using >> this over `--security-properties /etc/crypto-policies/back-ends/java.config` >> is that the system policy file could be updated async to the `jlink` command >> being run. > > The main issue I see with supporting the `include` directive is that its > position relative to other properties is important. This is described in the > [CSR](https://bugs.openjdk.org/browse/JDK-8319333): > > > The effect of each definition is to include a > referred security properties file inline, adding all its properties. > Security properties defined before an include statement may be overridden > by properties in the included file, if their names match. Conversely, > properties defined after an include statement may override properties in > the included file. Hi @seanjmullan, sorry if you already discussed this, but have you considered just appending the contents of `<filename>` at the end of `java.security`? Is there any other downside, besides the increased size of the resource file? If the most likely use-case doesn't override a bunch of properties, the size waste could remain moderate. That approach would automatically address the properties overriding (`<filename>` content goes after `java.security` content) and support `include` directives, without the need to parse the properties files and manually track the overrides. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30635#discussion_r3059821331
