On Thu, 9 Nov 2023 21:36:44 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> 8319332: use Path::of(URI) to deal with file URLs >> >> Instead of the previously introduced FileURLConnection::getFile(), use >> Path::of(URI), leaving some file URL corner-cases without relative >> imports support. >> >> Further details in >> https://github.com/openjdk/jdk/pull/16483#discussion_r1382111155 >> >> Co-authored-by: Martin Balao <mba...@redhat.com> >> Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > > My major concern is that this does not look like a properties file anymore, > that the same key have multiple values and you use an undocumented (?) format > "key value". That said, this is a clever hack and I wonder why we hadn't used > it for `security.provider`s. Hi @wangweij, ---- > My major concern is that this does not look like a properties file anymore, > that the same key have multiple values and […] We understand your concern. While the existing syntax has not changed, the special semantics assigned to _include_ properties set them intentionally apart. Perhaps we should refer to them as directives, instead of special properties. More than having multiple values, it's that they have effect at properties processing time and over properties themselves. In any case, we agree that users who take advantage of this feature will need to read about this behavior. We considered the following to make it more intuitive: 1. By making a purposeful distinction between `'='` and `' '` throughout the documentation of this feature, we can stress the difference and gain some clarity. For example: ```properties key1=value1 key2=value2 include other/file.properties key3=value3 ``` 2. The word "include" is suggestive of action and, as it does not carry any security related meaning, looks orthogonal to the security domain. If users relate this word to a metaproperty, its special semantics and effect would be within expected. Having a recognizable path as a value for this property should be congruent with including something external. 3. There are several examples of software that use this concept of including an external source into a configuration file, and most of them use a variation of the word "include". To name a few: [OpenSSL](https://www.openssl.org/docs/man1.1.1/man5/config.html#:~:text=Other%20files%20can,ignore%20the%20include%2e), [OpenSSH](https://man7.org/linux/man-pages/man5/ssh_config.5.html#Include:~:text=it%2e-,Include,inclusion%2e), [Git](https://git-scm.com/docs/git-config#_includes) and [Apache HTTP Server](https://httpd.apache.org/docs/2.4/mod/core.html#include). For users with software development experience, "include" might sound familiar to the C preprocessor and macros. ---- > […] you use an undocumented (?) format "key value". […] While this is probably not the most extended syntax in use, it is documented in [`java.util.Properties::load(Reader)`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Properties.html#load%28java.io.Reader%29): > _The key contains all of the characters in the line starting with the first > non-whitespace character and up to, but not including, the first unescaped > '=', ':', **or white space character** other than a line terminator. All of > these key termination characters may be included in the key by escaping them > with a preceding backslash character;_ ---- > […] That said, this is a clever hack and I wonder why we hadn't used it for > `security.provider`s. Do you mean something like the following? key1=value1 register.security.provider SUN register.security.provider SunRsaSign register.security.provider SunEC register.security.provider SunJSSE register.security.provider SunJCE register.security.provider SunJGSS register.security.provider SunSASL register.security.provider XMLDSig register.security.provider SunPCSC register.security.provider JdkLDAP register.security.provider JdkSASL key2=value2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-1805553323
