Sean,

> On 20 Jul 2018, at 18:07, Sean Mullan <sean.mul...@oracle.com> wrote:
> 
> On 7/20/18 11:08 AM, Chris Hegarty wrote:
>> This is ambiguous, and needs to be clarified. Surely, it is
>> better to use the same wording as the serial filter:
>>  "Whitespace is significant and is considered part of the value."
> 
> Kind of on the fence on that one. If this were a general property/value 
> format, I would agree, but these values are fixed and not potentially 
> complicated expressions.

Sure, they are simple strings consisting of only printable characters.

> For example, does this mean:
> 
> jdk.includeInExceptions=hostInfo,jarInfo
> 
> and
> 
> jdk.includeInExceptions=hostInfo, jarInfo
> 
> are different? And I assume the latter " jarInfo" would be ignored?
> 
> If you are strongly in favor of this, I would highly recommend logging a 
> warning when there is an unknown value, otherwise typos and such would be 
> hard to detect (although this doesn't necessarily need to be in the 
> specification).

My original whitespace handling avoided the potential issue where a 
rogue lead or trailing whitespace accidentally found its way into a
value, therefore avoiding the scenario above ( and potentially emitting
a warning ).

Whitespace is significant and should be specified as such, since ...
  
  jdk.includeInExceptions=“host   Info” 
    IS NOT equal to
  jdk.includeInExceptions=“hostInfo”
    and system property values can contain spaces
  jdk.includeInExceptions=“foo bar,hostInfo,jar Info,” 

After given this some more thought, I now think that I gave in to the
comment to change whitespace handing too easy. While maybe not
consistent, with the already inconsistent, whitespace handling in
java.security, I think ( for this particular case ) the original - trim
leading and trailing - is the right thing to do. It avoids your above
scenario where someone accidentally adds a leading space, which could be
difficult to debug/find without a warning - which we should avoid if
possible.

I’d like to re-propose the original webrev for consideration ( whitespace
handling is the only change ):

  http://cr.openjdk.java.net/~chegar/8207846/webrev.00/


-Chris.

Reply via email to