Reviewer and committer request for 7198496

[Alan Bateman]

On 04/10/2012 15:39, Paul Sandoz wrote:
> :
> I thought that was the case too, my first webrev had the if/else removed but then i updated it after i read the JavaDoc of ClassLoader.getSystemClassLoader():
>
>    Returns: The system ClassLoader for delegation, or null if none
>
> Paul.
Yes, the spec allows there to be no system class loader.

So my take on ServiceLoader is that the changes in your updated webrev 
are okay. Code that wants to allow for service providers to be be 
installed on the class path or located via the TCCL should use the load 
methods. Code that wants to restrict things to only service providers 
that in the extensions directory or the boot class path needs to use 
loadInstalled instead. It's hard to know how common the 
TCCL=null+load(S) or load(S,null) cases are but the spec seems clear and 
with the changes then I don't think there should be any issue.

As regards the Thread set/getTCCL methods then I think the null case is 
a bit of a corner case. The methods specify the intended usage but can't 
of course enforce it. My guess is that for regular applications is not 
an issue,the primordial thread starts out with it set to to the system 
class loader and other threads inherit it. I also suspect this is a 
non-issue for the EE apps too as I gather it's always set there because 
there are multiple contexts running in the same container. There can be 
security or GC reasons to reset it to null but that should be rare, at 
least outside of the JDK.

-Alan