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