[9] RFC JDK-8068373: (prefs) FileSystemPreferences writes \0 to XML storage, causing loss of all preferences

[Roger Riggs]

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.sandoz at 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