Changes Look fine. Nice test too. -Chris
On 12 Oct 2012, at 11:19, Alan Bateman <[email protected]> wrote: > > A few days ago we added a JDK private provider interface [1] to which the > Properties loadFromXML and storeToXML methods will delegate. The motive as I > mentioned is to allow for a smaller environments where JAXP might not be > present (so motivated by both modules and the compact profiles work). > > 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/ > > 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. > > -Alan. > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f65871e75fde > [2] http://www.w3.org/TR/REC-xml/#charencoding
