CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)

Joe Wang at
Fri Dec 7 08:04:45 UTC 2012

I would think that it's good to merge the 3rd and 4th steps for a jdk in 
module mode. In regular mode or JDK8, where the existence of the default 
implementation is guaranteed, the last step is still necessary.  It is a 
requirement for the API implementation.

I probably was wrong to use "default" to refer to the jaxp ri at the 3rd 
step of the service mechanism. After reading your comments/discussions, 
I felt it might not be appropriate for regular JDKs or JDKs in regular 
mode. Users may well, as they should, take what's installed within the 
JDK as the "default" implementation and be confused with the statement 
that the "default" may not be present.

So it looks like we need to differentiate regular from modular JDK, and 
more importantly the jaxp ri from the "default" implementation:

1) In regular JDK (e.g. JDK8), the service loader shall return the first 
provider (whether it's a 3rd-party impl or the jaxp ri, it's users' 
decision to put them on the classpath or in the endorsed directory)

     The 4th step is still "Platform default 
<code>DocumentBuilderFactory</code> instance."

2) In module mode, the default impl would be one of the modules. My 
understanding is that there would not be such a thing as a JAXP RI 
module. So merging 3rd and 4th steps are fine. But it may be necessary 
to clarify that it's for module mode.


On 12/6/2012 9:38 AM, Daniel Fuchs wrote:
> Updated the javadoc for newInstance():
> <> 
> -- daniel
> On 12/6/12 11:04 AM, Alan Bateman wrote:
>> On 05/12/2012 16:17, Daniel Fuchs wrote:
>>> Hi,
>>> Please find below a revised version of the changes for
>>> the javax.xml.parsers package.
>>> It hopefully incorporates all comments I have received so far.
>>> <> 
>>> * better wording/formating for Javadoc changes
>>> * using for( : ) syntax in findServiceProvider
>>> * improved // comments explaining why the additional layer of
>>>   RuntimeException is needed when wrapping ServiceConfigurationError.
>>> best regards,
>>> -- daniel
>> You've addressed all my comments and I think this looks very good.
>> One other comment. Now that the wording is "Otherwise the default
>> implementation, if present, is returned" it raises the question as to
>> how what happens if the default implementation is not present. A
>> suggestion is to just handle it in the next statement, something like
>> "In the case of a SCE or the default provider is not present, then FCE
>> will be thrown".
>> I see Mandy's comment about the bullet item "Platform default
>> <code>DocumentBuilderFactory</code> instance". I hadn't noticed this but
>> I assume this should just be removed now.
>> -Alan.

More information about the core-libs-dev mailing list