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

Joe Wang huizhe.wang at oracle.com
Fri Aug 24 16:52:11 UTC 2012


Here is a modified patch: 

The factory finders contain some format changes, a NetBeans format work. 
The real changes are as the follows:

1) In factory classes: reinstated the implementation resolution 
mechanism, the 3rd step mainly

2) In factory finders: replaced findJarServiceProvider with 

3) In factory finders: removed ConfigurationError class, using 
FactoryConfigurationError instead

Please review.


On 7/29/2012 11:59 PM, Joe Wang wrote:
> Hi Paul, Alan,
> I'm back on this change.
> On 6/25/2012 12:19 PM, Joe Wang wrote:
>> On 6/25/2012 9:34 AM, Paul Sandoz wrote:
>>> H Joe,
>>> I just focused on javax.xml.datatype and assumed the rest follows 
>>> the same pattern :-)
>> Yeah, they are mostly similar, except Schema and XPath that do a 
>> little extra check.
> I said too quick.  Yes, the steps are the same except for the 
> validation and XPath.  But it happened that DatatypeFactory is the 
> only one that had defined Exception in the 3rd step. All others were 
> made to ignore any error, since in the regular JDK, we can always fall 
> back to the default impl unless requested not to.
> I've made all of the changes as we've discussed,  to catch the 
> ServiceConfigurationError and pass on the cause for all of the 
> factories/finders.  I wanted to post the change so that you could see 
> them on Mon.  But I had to read the definitions again when I got to 
> the SchemaFactory and noticed that it was the only one that did not 
> have its own exception. Instead, it was defined to always throw IAE if 
> no impl is available.
> As I thought through these definitions, I felt I would probably change 
> them back although I started to hate the tedious duplications as you 
> expected :)   Indeed, I have to argue again, in the regular JDK, 
> there's no need to catch any errors since they would be considered 
> abnormal (Windows' blue screen came to my mind).  And in jigsaw, we 
> shall only need to figure out a different error message when no 
> provider is available, only if we wanted it to be more end-user friendly.
> -Joe

More information about the core-libs-dev mailing list