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

[Mandy Chung]

Alan,

Nice work and this sets a step toward the future to allow Properties to 
use a different XML parser implementation.  When there is a small 
footprint parser that Joe is working on, Properties no longer requires 
JAXP to be present.

> http://cr.openjdk.java.net/~alanb/8000354/webrev/ 
Properties.java L1157 - since loadProviderFromProperty method is called 
within a doPrivileged block, it doesn't seem to be necessary to catch 
SecurityException.

It uses the system class loader to load the service provider.  It's fine 
as it currently only supports the one provided by the platform (JAXP) as 
the SPI is internal; otherwise, it may be appropriate to use 
ServiceLoader.loadInstall.  What you have is fine.

test/java/util/Properties/LoadAndStoreXML.java
    It's good to test the cases with and without security manager.
    Could the test run both cases in the same VM (or even in the same 
test) if you explicitly save the SecurityManager before the test runs 
and restores it after the test finishes?  It's minor and I just thought 
that we might want to avoid othervm tests if possible.

Looks good otherwise.
Mandy

On 10/5/2012 6: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