8000354: (props) Properties.storeToXML/loadFromXML need to allow for alternative implementations

[Jim Gish]

Looks good, Alan.

A minor typo:
  For the javadoc of private static class XmlSupport (line 1128 of 
java/util/Properties.java), probably should say "fully qualifed name" 
rather than "full-qualified name"

Jim

On 10/05/2012 09:41 AM, Alan Bateman wrote:
>
> Properties defines the loadFromXML and storeToXML methods for 
> loading/storing properties in XML format. These methods are 
> problematic for our efforts to modularize the JDK because of the 
> dependency on XML. They are also problematic for the Compact Profiles 
> proposal [1] as it is unlikely that JAXP will be present in the 
> smallest profile.
>
> As the XML parsing needs of Properties is relatively simple we are 
> thinking about including a small footprint parser that is sufficient 
> for its needs. Joe Wang is looking this. In preparation for this we 
> need to decouple Properties from the parser API that it uses and this 
> is what the proposal here is about.
>
> The webrev with the proposed changes is here:
>
> http://cr.openjdk.java.net/~alanb/8000354/webrev/
>
> Basically it introduces a JDK internal provider interface to which the 
> loadFromXML and storeToXML methods delegate. The existing code that 
> uses JAXP is moved into a provider implementation and will be used 
> when present. When not present then the intention is that it will 
> fallback to a default implementation that is the small footprint 
> provider that Joe will add later. This approach ensures that we 
> maintain compatibility (it remains to be seen whether we will have to 
> deal with a few subtle issues when using the tiny parser). For test 
> purposes there is a system property for overriding the provider, this 
> is also why the system class loader is used as the initiating loader.
>
> I should explain that when I say  "JDK internal provider interface" 
> then the service type is in sun.util.spi for now. Maybe in the future 
> it may be necessary to define a standard provider interface but it is 
> not needed at this time (in addition it would require getting the 
> security right to do that).
>
> Thanks,
>
> Alan.
>
> [1] http://openjdk.java.net/jeps/161

-- 
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.gish at oracle.com