8000685: (props) Properties.storeToXML/loadFromXML should only require UTF-8 and UTF-16 to be supported

Mandy Chung mandy.chung at oracle.com
Fri Oct 12 22:43:34 UTC 2012

On 10/12/2012 3:19 AM, Alan Bateman wrote:
> ...
> The next step in this effort is dealing with the issue of arbitrary 
> encodings. The storeToXML method allows the encoding to be specified, 
> the loadFromXML method assumes that the implementation can decode the 
> stream and read the encoding declaration. The specification doesn't 
> make it clear how either method behaves with unrecognized encodings 
> and this is something that we need to fix in order to allow for 
> alternative implementations, in particular tiny parsers that might not 
> support more than a few.
> The webrev the proposed changes is here:
> http://cr.openjdk.java.net/~alanb/8000685/webrev/

This looks good to me.

> The proposal is that an implementation minimally supports UTF-8 and 
> UTF-16, which I think is consistent with the W3C XML specification [2].
> Based on a search of a large number of projects then it appears that 
> these methods aren't used very much so I don't think this will have 
> any significant impact. In addition the same set of encodings [ which 
> is not exactly the same set as Charsets.availableCharsets().keySet() ] 
> that works today will continue to work when the service provider that 
> uses JAXP is installed.
> In addition, to specifying the required encodings, I have also changed 
> both methods to specify that UnsupportedEncodingException may be 
> thrown. In the case of loadFromXML then this is the long standing 
> behavior anyway. In the case of storeToXML then the long standing 
> behavior is somewhat bizarre. If the method is invoked with an 
> unsupported encoding then the underlying Xalan code prints a warning 
> to System.out and changes the encoding under the covers to UTF-8. I've 
> submitted a bug on this oddity; in the mean-time I've added a check in 
> the platform provider to always fail for charsets that aren't recognized.

Good find.


More information about the core-libs-dev mailing list