ServiceLoader in the JDK

[Paul Sandoz]

On May 23, 2012, at 7:04 PM, David M. Lloyd wrote:

> On 05/23/2012 11:31 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Here is some proposed changes in the JDK related to service loader
>> (not tested yet! just want some easily feedback):
>> 
>> http://cr.openjdk.java.net/~psandoz/jigsaw/jdk-services/webrev/
>> 
>> I have attempted where possible to tidy things up to avoid an
>> explicit reference to a class loader for common patterns hence the
>> addition of the methods ServiceLoader.loadFromClass,
>> ServiceLoader.loadFromSystem and ServiceLoader.loadFromCaller (when
>> in module mode most ServiceLoader.load* method do the equivalent of
>> the latter). The names could be better.
> 
> You really don't want to have loadFromCaller().  We experimented with this and found the performance cost to be unjustifiable, especially when you consider what a simple matter it is for the user to pass in their class loader.  The recommendation that we make to users in ##java as well as internally and externally here at JBoss is to always use the three-argument form of Class.forName() for this reason as well.
> 

Thanks, good to know.


> Changing load() to depend on the mode is hazardous!  There is a lot of code that assumes it is using TCCL.  You cannot make TCCL go away.  It is *well-established* to mean "the current application", of which there may be more than one in the VM and it may well be a different module than the one calling load() (in fact this is very likely to be the case in Java EE).
> 

Yes, it's everywhere in EE land. TCCL is currently problematic with modular mode and service loading as the CL of the module declaring the "requires service" needs to be used.

The whole area of containers still needs to be fleshed out, including what impact that has on services.


> By depending on mode, the loadFromSystem() semantics are very unintuitive.  I would not use this method and would discourage users from using it for this reason.
> 
> Overall I find this change to be very discouraging, and also very naive.
> 

No doubt :-) discourage ye not, it's a failed experiment that has received some very useful feedback from yourself and Alan and Jesse. 

What i am hearing is the approach to try and avoid the caller declaring the class loader and inferring the class loader is the opposite direction of where we should be going with this, and instead either the class loader should be explicitly declared or some other context (as Jesse points out) should be explicitly declared from which the class loader can be efficiently obtained.

I also tried to avoid "if (Platform.isModuleMode()) { ... } else { .... }" blocks for code calling ServiceLoader, but perhaps that is unavoidable if it is not possible to be explicit with a single call to ServiceLoader encapsulating classpath and modular mode behaviour.

Paul.