ServiceLoader.load* take 2

[David M. Lloyd]

I have a high level of concern about "tactical and temporary solutions" 
and things that "might often" work.  Here's what this looks like to me.

1. We have an existing solution that does the job.
2. It isn't Jigsaw-ish enough; let's instead create a new service thing 
that is Jigsaw-ish.
3. New service thing is conceptually divergent from original thing; now 
let's put in a lot of nasty hacks to make it kinda sorta work. 
Especially if we can use heuristics - heuristics are neat!
4. (and this is the next step) Yowee, we really screwed things up - now 
new apps are screwy *and* old apps don't work with any semblance of 
predictability.  A formerly reliable and predictable core API now is 
unusable for both old and new apps.

Guys the existing service loader mechanism works well with multiple 
class loaders as is.  I don't understand what the thinking is here.  It 
isn't broken, and yet it is being fixed.

I think that the classpath vs module mode discrepancy is the ultimate 
realization of this sort of thinking.  There is a basic assumption that 
such a split is needed; the technology is then implemented to realize 
this, and then becomes its own justification.  But such a discrepancy 
should not be necessary.  If an old-style classpath application cannot 
run in module mode then not enough effort was put forth in terms of 
compatibility.

Note that so much of this service loader solution is predicated upon two 
modes!  Red flag?

On 06/12/2012 10:03 AM, Paul Sandoz wrote:
> Hi,
>
> A set of slides has been created [1] which presents a set of terms, an overview of modular services, describes the current state of affairs with service instance creation and the use of ServiceLoader.load*, then proposes an alternative solution for ServiceLoader, the first part of which is implemented by the following webrev, which changes service instance creation so that it is scoped to the configuration rather than the class loader:
>
>    http://cr.openjdk.java.net/~psandoz/jigsaw/global-services/webrev/
>
> Summary: in module mode any module class loader can be used with ServiceLoader to create the service instances for a service interface. Previously the class loader of the service consumer module, that consumes the service interface, was required to be used.
>
> Next steps:
>
> - Modify the configuration so that service information is stored directly with the configuration rather than with each context (that is stored with the configuration). Currently service provider classes are looked up by iterating through all the contexts. This is not very efficient. The configuration is the place where to optimize.
> This requires some refactoring of org.openjdk.jigsaw.Configuration because for instances of Configuration<PathContext>  (the configuration produced when compiling) such state related to services is not relevant. This is also a potential opportunity to improve the immutability of Configuration using a builder pattern for construction.
>
> - Modify the resolver so that the permits clause does not affect resolution of a service provider module (and it's dependencies). This area is tricky. Rather than choices of service provider module optional dependencies being pushed on to the choice stack of each service consumer module this potentially could be done once per service interface (although will likely change what solutions are produced), but might be very tricky to implement given that service provider modules may also be service consumer modules. Good diagnostics are required to help track down why a service provider module is not being resolved.
>
> Paul.
>
> [1] http://openjdk.java.net/projects/jigsaw/doc/openjdk-jigsaw-modular-services.pdf


-- 
- DML