On Feb 12, 2015, at 9:29 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
>>> Yes, for an interoperable format potentially read by other tools having >>> U+0000 is a really bad idea. >> >> Yep. >> > > And i think that applies to plist files too. I cannot confirm but I heard otherwise. I’ll test it. >>> 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. > > My recommendation is serialization of properties to any textual format should > barf if a U+0000 is encountered. Otherwise it's just hiding bugs. In such > cases i think there is a strong justification to introduce such an > incompatible change. I except it is rare to encounter in practice. I cannot argue with that. I will revise and re-post the patch and see what the consensus says. Thanks for the input. Brian
