On Fri, 10 Nov 2023 17:33:33 GMT, Weijun Wang <wei...@openjdk.org> wrote:
> > By "the same key has multiple values", I assume you mean the key "import"? > > The implementation overrides `put` and swallows these `include` lines so > > they are never actually added as keys and values. > > Yes, I understand this, and this makes `java.security` no longer a real > properties file. If you are able to convince core-libs to adopt this new > "directive" for all properties files, I'm all OK to make use of it in > `java.security`. `java.util.Properties` instances are not necessarily backed by a filesystem file. Its APIs refer to more generic Readers, Writers and InputStreams. In that context, an "include" directive with the semantics that we assigned in this proposal could be undefined, or not in the right place. We originally looked at this as a specialization for the purposes of security configurations in OpenJDK. But even in that narrow space we had to consider served extra properties files (e.g. `-Djava.security.properties=http://...`) and reject their relative-path includes. Java applications can specialize `java.util.Properties` to define their own semantics, and do not need to be limited by ours. For example, they may allow URLs to get remote resources —something that we shouldn't do for security or network configurations. At some point we thought that this idea could be extended to other file-based configurations in OpenJDK such as network, but we didn't see a need at the moment that justifies a broader scope. My point is that `Properties` do not necessarily need to look and behave in the same way, because this is a public and (intentionally) open API already. Another example of customized behavior has been `java.security.Provider`. We proposed a documented instance of it for the purposes of security configurations, that allows some extra flexibility. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1806461459
