RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader

[Joe Wang]

On 8/30/2012 2:20 PM, Alan Bateman wrote:
> On 30/08/2012 19:38, Joe Wang wrote:
>> Hi Paul, Alan,
>>
>> I've read your latest comments.  Before getting back to you on those 
>> items, I felt it's important we get the classloader handling 
>> correctly.  If it's as what I suspected (as I described in the last 
>> email), we may have problem with using ServiceLoader.
>>
>> I've read Paul's explanation, esp. the delegation to 
>> ClassLoader.getSystemResourceAsStream part.  It looks right as it's 
>> stated in the spec.  But I do remember it was the issue for CR6723276 
>> and I did change it to Object.class.getResourceAsStream (without a 
>> way to call bootstrap classloader).
>>
>> Just as Paul said, the classloader stuff is quite tricky.  I had 
>> three dummy jars that I've been running tests with.  I haven't had 
>> problems loading those jars.  But the tests were under 'normal' 
>> conditions, that is, the usual jdk classloader hierarchy was followed.
>>
>> Also, dummy jars may work. But I should at least test Xerces. So 
>> that's what I'm going to do as well.
>>
>> --Joe
> I don't think I'm following the concern here as I thought the 
> SecuritySupport will either give you the TCCL or the system class 
> loader (but never null). As I quick check I created a no-op 
> SchemaFactory, packaged it up with 
> META-INF/services/javax.xml.validation.SchemaFactory into a JAR and 
> verified that it was located when I deploy it on either the class path 
> or extensions directory. In this case, the thread invoking 
> SchemaFactory.newInstance had its TCCL set to the system class loader 
> (the default). Same thing if I change the TCCL to null because 
> SecuritySupport gives the Finder the system class loader for that case.

Yes, it works just fine under normal conditions.

Note the old process: read the service file using TCCL (if null, system 
cl), if nothing found, then BCL

Somehow I was under the impression ServiceLoader does just that so that 
we could delegate to it.  It's probably a good thing that it actually 
doesn't. If it did, it'd cause error in the following case:

    The TCCL's parent is BCL  (that is Bootstrap), a jaxp impl (e.g. 
Xerces) is on the classpath
     Old process: try TCCL, not found, try BCL, not found
     ServiceLoader: use TCCL, not found, return null  (I thought it'd 
continue using System CL, but it didn't)

     **although worked differently, the results are the same, so not an 
issue in terms of the result, still a behavior change though.

I did many tests, but so far the results are the same before and after 
the patch.

If TCCL is set to null, I actually saw SCE other than SchemaFactory, for 
example:
javax.xml.stream.FactoryConfigurationError: 
javax.xml.stream.XMLEventFactory: Provider 
org.apache.xerces.stax.XMLEventFactoryImpl not found

--Joe

>
> Paul - slap me in the face if I have this wrong, I don't want to cause 
> any confusion on this, I really just want to see a current vs. 
> proposed behavior for each of the finders.
>
> -Alan.