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

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 DocumentBuilderFactory 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