On Fri, 3 May 2024 20:46:46 GMT, Martin Balao <mba...@openjdk.org> wrote:
>> src/java.base/share/conf/security/java.security line 70: >> >>> 68: # an error is thrown and explicit profile selection is required. In >>> order >>> 69: # to override properties defined in this file, the include statement >>> may be >>> 70: # placed at the end. >> >> Same with this paragraph. I think it is ok/useful to include the 3 examples >> but explaining how one might deploy the include files with FIPS as an >> example is more for a programming guide. Also, some text is repeated - you >> already indicated an error is thrown if a file does not exist and the >> property defaults to the empty string. >> >> The one sentence I found useful is the last one - but I think you could move >> this as the last sentence of the first paragraph and it would have more >> impact. I would change "may" to "should". > > We completely agree with removing the description of this particular case > from the _java.security_ file for the same reasons as before. In regards to > the last line, we would remove it as well. It's explained in the first > paragraph that included files are _inlined_ into a security properties file. > The paragraph continues with a description of what _inlining_ means. The > comment about placing the include statement at the end is a particular > configuration and can be logically inferred from what _inlining_ is and what > the user goals are. I would abstain from recommending particular > configurations and let the user make their own analysis and choice. It may be > the case that some properties should not be available for profiles and will > then be intentionally overwritten in the _java.security_ file after the > include statement. That's fine, I think your rationale to not include it makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16483#discussion_r1589769595
