Hi Roger, Thanks for taking the time to review this recap. Your suggestion to forge ahead with the approach already taken seems to be reasonable. I concur that a fail-fast approach of throwing an IAE as soon as the bad character is encountered if preferable to waiting for some inscrutable subsequent exception in flush() or sync().
So barring objections to the contrary from some other quarter, I will clean up the current patch and also address the errors in the class level javadoc that I pointed out in AbstractPreferences. Thanks, Brian On Apr 14, 2015, at 8:00 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > Thanks for digging deeper and the recap. > > I don't see any cases in which it is necessary or valuable to allow > \0 in Strings (key or value). The original bug report did not indicate > whether > it was discovered as a testing exercise or when diagnosing a bug in an > application. > The compatibility risk is unknown at the moment since no cases have been > noted that require \0 in strings. > > Long term the code will be easier to maintain if it is less complex and has > fewer > variables that are platform or format specific and developer errors are > detected > as soon as possible. > > Of the possible remedies below, #2 seems the most practical. But it will > further > hide the problem from developers since calling flush and sync is never > required > for correct operation: > ///"explicit //flush//invocation is //not//required upon termination to > ensure that pending updates are made persistent"/ > Flush and sync would be the only opportunity to throw an exception and > explain the cause. > It will be harder to track down since the true cause will be far removed from > the time/location of the exception. > > In the absence of advice to continue to support \0in Preference strings on > Windows > or Mac I'd continue with the recent direction to make \0 in key and value > strings throw IAE.
