Caller context (was: ServiceLoader in the JDK)

[Jesse Glick]

On 05/23/2012 12:31 PM, Paul Sandoz wrote:
> ServiceLoader.loadFromCaller

A general comment: it would be nice to deprecate APIs whose behavior varies according to the identity of the caller. While these may be convenient, they violate 
referential transparency. Among other things, this breaks automated refactoring tools: for example, "extract method" into a utility class in a common module could result 
in a helper method which actually loads different services than original direct calls to ServiceLoader would have! (Depending on how multitenancy gets implemented for 
something like Java EE based on Jigsaw.)

If some sort of "module context" is needed, best to make this explicit. Most simply, add a 'Class<?> caller' parameter. So:

   for (ServiceLoader.load(Service.class, ThisClient.class)) {...}

would iterate all instances of Service provided by modules in the configuration which loads the module defining ThisClient.

Of course you could ignore the caller entirely and use a context available statically - i.e. a global (singleton) module configuration, or based on the context class 
loader as in nonmodular mode, or based on the thread group. Whether such shortcuts would work well under multitenancy is another matter.