CFR: javax.xml.parsers: Using ServiceLoader to load JAXP parser factories (7169894: JAXP Plugability Layer: using service loader)
huizhe.wang at oracle.com
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
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:
>>> 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.
More information about the core-libs-dev