RFR of 8075156: (prefs) remove() should disallow the use of the null control character '\u0000' as key
Alan.Bateman at oracle.com
Sat Apr 4 19:53:46 UTC 2015
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).
More information about the core-libs-dev