Hi Brian,
I think its worth the overhead of cleaning up the spec and
the backward compatibility risk is low given the XML restriction.
(Though perhaps not directly back-portable to 8 without the spec change)
Roger
On 2/12/2015 11:27 AM, Brian Burkhalter wrote:
On Feb 12, 2015, at 8:18 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
This is a morass and I hope that someone more apt to know it well would
comment. The U+0000 null control character is always illegal though I do know
that.
Yes. IIRC XML 1.1 basically allows any character except U+0000.
"Note that the code point U+0000, assigned to the null control character, is the
only character encoded in Unicode and ISO/IEC 10646 that is always invalid in any XML 1.0
and 1.1 document."
http://en.wikipedia.org/wiki/Valid_characters_in_XML#Characters_allowed_but_discouraged
The problem is that on OSX and Windows prefs are not stored to XML
What are they stored in? name/value pairs?
Yes. On OSX I think Property List (.plist) files; on Windows I do not know yet.
whereas on Unix they are.
Is that a specification requirement?
No, I think it’s an artifact of no inherent DB-like facility in the system.
That would make it an error to add such a value to the prefs on some platforms
but not on others.
Yes, for an interoperable format potentially read by other tools having U+0000
is a really bad idea.
Yep.
My inclination is if properties are written out to a text file then it should
fail if a key/value contains U+0000 (Binary data should be base64 encoded in
such cases.) Replacing just subtlety hides or defers the issue.
That was my original idea \in fact (webrev.00, unpublished). It would however
require a spec update to
http://docs.oracle.com/javase/8/docs/api/java/util/prefs/Preferences.html#put-java.lang.String-java.lang.String-
to allow for an IAE in this case. This would also be a backward-incompatible
change for platforms which do allow storing such values.
Note that a similar situation applies to Properties.
Thanks,
Brian
