On 24/03/2015 19:20, Brian Burkhalter wrote:
Please review at your convenience.
Issue: https://bugs.openjdk.java.net/browse/JDK-8075156
Patch: http://cr.openjdk.java.net/~bpb/8075156/webrev.00/
This is a sequel to the resolved issue
https://bugs.openjdk.java.net/browse/JDK-8068373, (prefs) FileSystemPreferences
writes \0 to XML storage, causing loss of all preferences, wherein the code
point U+0000, the null control character, was made illegal to use as a key in
the generic Unix file system-based Preferences.
The issue at hand extends disallowing U+0000 as a key in the put() method on
Mac OS X and Windows, and also disallows this use to the remove() methods on
these platforms and in the generic Unix file system-based Preferences.
Use of U+0000 in the corresponding get() method has not been disallowed as this
method returns a default value. If it would be preferable that the behavior of
get() with respect to the key U+0000 were the same as for put() and remove()
then this patch may be updated to that effect.
Minimally then the putXXX methods should make it clear that they throw
IAE for this case. This would be a javadoc only change because the
implementation does this as a consequence of the original patch.
In the original discussion then it was just a question as to whether
get/getXXX and remove should be consistent. If the get and remove
methods will always behave as if the key doesn't exist (and return the
default value in the case of get) then it shouldn't require a javadoc
change. However I suspect it will require an implementation change as
there may be non-XML backing stores might that allow \0 in the key
(hence get and remove should actually do something).
-Alan.
