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

Alan Bateman Alan.Bateman at oracle.com
Sat Sep 1 12:02:10 UTC 2012

On 31/08/2012 18:12, Joe Wang wrote:
> :
> Okay,  let's streamline the factories.  I think we should:
> 1) align to the SAX/DOM since these are most frequently used, and 
> proven.  Any changes to other factories will have lower impact in 
> comparison;
> 2) no spec change involved:  for example, the StAX factories have 
> newFactory/newInstance(String factoryId, ClassLoader classLoader), 
> while others define the first parameter as factory classname, e.g. 
> newInstance(String factoryClassName, ClassLoader classLoader).  We 
> also know that some factories have throws clause while others don't.  
> In this effort of making factories behave consistently, we'll restrain 
> from making any spec change.
SecuritySupport.getContextClassLoader for the parsers looks like it does 
the right thing and it would be good to get that propagated to the other 
places where it's not quite right.

On spec changes then I think they will need to be examined. You mention 
StAX but when I read the javadoc for methods such as 
XMLEventFactory.newFactory then it has wooly wording such as " The 
Services API will look for a classname in the file 
META-INF/services/javax.xml.stream.XMLEventFactory in jars available to 
the runtime". I think part of the reason for the inconsistent lookup 
throughout this API is that it wasn't properly specified in the first 
place so it needs to be on the radar to get the specification sorted out 
too. Whether this is done as part of sorting out the factory finders or 
as part of changing the code to use ServiceLoader probably doesn't 
matter I guess. However, I think we do need to create a table of 
specified behavior, actual behavior, and proposed behavior for each 
factory and for each of the security manager vs. no security manager 
cases too.

The other thing for a first phase is a good set of tests. They are going 
to be needed to understand the before and after behavior anyway.


More information about the core-libs-dev mailing list