ServiceLoader.load* take 2
Paul Sandoz
paul.sandoz at oracle.com
Fri Jun 15 08:23:15 PDT 2012
On Jun 15, 2012, at 1:09 PM, Alan Bateman wrote:
> On 12/06/2012 16:03, 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.
>>
> I skimmed through the webrev and the changes look reasonable to me. It's good to have the hacks removed from ServiceLoader, as you know these were needed to avoid a pit stop to change the gear box. I'm also happy with that the proposal addresses the permits issue, that was a left-over open issue from the first installation. With the proposal then it's much simpler and is conceptually equivalent to have all the service providers on the class path.
>
Exactly.
> One thing I didn't quite get was the reason for moving LazyIterator1 out of ServiceLoader to a new org.openjdk.jigsaw.ModuleServiceLoader. My comment is really just wondering about the iteration/instantiation in two places rather than one.
>
I wanted to separate concerns so that ServiceLoader did not know any specifics of modular services (and vice versa FWIW). It should hopefully keep any future changes located in the org.openjdk.jigsaw package. I forgot to do so but it means, for example, we can make Loader.findServices protected or package private.
> You listed in the "next steps" that the configuration needs to be updated to include a map from the service interface to the list of service provider modules that supply implementations and it would be good to do that (as it's regressing to have to check every context for service implementations).
>
Yes, i hope you don't mind me doing that as second commit. My preference is to do the next step properly with a refactoring of Configuration/Context instead of one commit that may have created a lot of ancillary noise around the core the issue.
> On the new test then it reminds me that we may be able to consolidate the tests in the services directory into a more complete set of unit tests (just thinking that there is a bit of duplication between the new test the existing hello.sh, many.sh and optional.sh).
>
What do you propose?
They definitely need to be fleshed out. Personally i prefer things to be in exploded form, i find it easier to grok.
Paul.
More information about the jigsaw-dev
mailing list