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.
Mandy
More information about the core-libs-dev
mailing list