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

[Remi Forax]

Hi Alan,
just some minor nits,
in Properties.XmlSupport, 'provider' should be PROVIDER because it's a 
constant and
instead of using loadProvider(), you should initialize PROVIDER in a 
static block.

line 1172, you declare a provider and line 1174, you initialize it,
I think line 1174 should do the declaration and the initialization on 
the same line.

cheers,
Rémi

On 10/05/2012 03:41 PM, 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