RFR: javax.xml.stream: Using ServiceLoader to load JAXP stream factories (7169894: JAXP Plugability Layer: using service loader)

Daniel Fuchs daniel.fuchs at oracle.com
Wed Jan 9 21:13:35 UTC 2013


Hi Mandy,

Please find clarifications in line:

On 1/9/13 9:30 PM, Mandy Chung wrote:
> On 1/9/2013 9:26 AM, Daniel Fuchs wrote:
>> <http://cr.openjdk.java.net/~dfuchs/JDK-7169894/javax.xml.stream/webrev.04/> 
>>
>>
>
> Daniel - thanks for updating the spec for the newFactory(String, 
> ClassLoader) method.
>
> In XMLEventFactory.java (and same comment apply to XMLInputFactory and
> XMLOutputFactory):
>
>    Since there is a behavioral change, the following statements are 
> not true
> any more and I think they can be removed.
>
>  166    * No changes in behavior are defined by this replacement 
> method relative
>  167    * to the deprecated method.
The behavior change is the same in both the deprecated & the new method 
- since
it occurred in the FactoryFinder which both methods are calling, so I
think this statement is still true.
>
> and
>
>  123    *              The replacement {@link
>  124    *              #newFactory(java.lang.String, 
> java.lang.ClassLoader)}
>  125    *              method defines no changes in behavior.
>
> L152: would it be better to replace "the base service class name" with
> the classname (i.e. javax.xml.XMLEventFactory)

Yes - I can do that. I was just being lazy :-)

>  152    *   If {@code factoryId} is the base service class name,
>  153    *   use the service-provider loading facilities, defined by the
>  154    *   {@link java.util.ServiceLoader} class, to attempt to 
> locate and load an
>  155    *   implementation of the service.
>
> The classLoader parameter passed to the newFactory(String, 
> ClassLoader) method
> is actually ignored.  It might be good to clarify that since the spec 
> is updated
> anyway.

I think it's a bug. I'm intending to log it as a separate issue. FWIW in 
the other factories
(in other packages) the classloader is not ignored.

So I think it would be wrong to document a bug :-)

-- daniel
>
> Mandy
>




More information about the core-libs-dev mailing list