RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader
huizhe.wang at oracle.com
Fri Aug 31 07:59:09 UTC 2012
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.
> 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
If TCCL is set to null, I actually saw SCE other than SchemaFactory, for
org.apache.xerces.stax.XMLEventFactoryImpl not found
> 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.
More information about the core-libs-dev