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.