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

Alan Bateman Alan.Bateman at oracle.com
Fri Dec 7 13:12:33 UTC 2012


On 07/12/2012 08:04, Joe Wang wrote:
>
> 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.
>
I think it's a bit premature to talk about modules and "module mode" in 
this specification. To use those terms would require somewhere to 
reference and there won't be anything to reference in Java SE 8. Also as 
this is a standalone technology then it can be used with implementation 
of previous Java SE versions too.

The way I look at this is that we are getting there in phases and a 
really important first phase for JAXP is to upgrade it to use 
ServiceLoader consistently. This is painful work due to 
under-specification and subtle compatibility issues that may arise due 
to these changes. Even without modules as a driver for this, then I 
think will be beneficial to JAXP anyway because it's cleaning up an area 
that is a mess today (not your fault, this pre-dates your watch).

If we can bring you around to agreeing with this then I think the only 
point remaining is whether the API requires at least one implementation 
to be present. I see your point and this may be something that needs to 
be deferred to a later time, in which case this requires changing the 
javadoc to:

"Otherwise the system-default implementation is returned."

and

"In case of {@link java.util.ServiceConfigurationError},then {@link 
FactoryConfigurationError} will be thrown."

Would you be okay with that? I don't think the javadoc should mention 
the JAXP RI, that may or may not be the system-default implementation.

-Alan.





More information about the core-libs-dev mailing list