Reviewer and committer request for 7198496 (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Thu Oct 4 20:56:35 UTC 2012


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



More information about the core-libs-dev mailing list