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

[Daniel Fuchs]

Hi Alan,

I have updated the webrev according to your suggestion. I think it makes
things much clearer.

The new version is there:

<http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.parsers/webrev.03/>


On 12/7/12 2:12 PM, Alan Bateman wrote:
> 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.
>
>