Services/configuration/context webrevs

[Paul Sandoz]

Hi,

I thought it would help to consolidate the service/configuration changes into one email. Each is like a plane circling in a holding pattern waiting to land at Heathrow...

I have also separated out the configuration/context refactoring into a separate webrev.


Service provider module resolution
-----------------------------------------------

http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.2/

- "permits" clauses do not affect service provider module resolution

- service provider module resolution occurs after "application" resolution. Essentially the application has to successfully resolve as if there were no "requires service " clauses present and after that service provider module resolution occurs.

I understand that on and off list there is reasonable agreement to go forward with this latter approach.


Service state on configuration
----------------------------------------

http://cr.openjdk.java.net/~psandoz/jigsaw/config-services/webrev/

An extension of Configuration called InstalledConfiguration that encapsulates state mapping service interface class names to context and service provider class names for more optimal service instance creation. This state is exposed as an Iterable of a tuple of Context and service provider class name. An Iterable, rather than a Map, assumes much less on the underlying state representation.

Context and persistence of service information is left unmodified. IMHO there is little benefit in separating this out. In terms of storage the service provider class names need to be associated with the correspond context. I felt it best to avoid duplication of context names in the persisted storage.

Note that Configuration already performs another optimization, creating the map of context for context name, and the refactoring changes (see below) create the map of context for module view/alias name.


Refactoring of configuration and context
------------------------------------------------------

http://cr.openjdk.java.net/~psandoz/jigsaw/config-refactor/webrev/

This is my attempt to refactor (or "curate" :-) ) the configuration and context classes to make "cleaner" the approach of building state of contexts and configurations then creating instances of contexts and configurations.

I have tried to reduce the assumptions between things in the process of resolving, context builder construction (grouping modules into contexts), and linking local and remote suppliers.

IMHO we need to gradually transition this code base from it's prototype-like state; much like Chris is doing for module file parsing/reading i am attempting to do for another area.


http://cr.openjdk.java.net/~psandoz/jigsaw/config-refactor/config-services-webrev/

The above webrev is the same as "Service state on configuration" functionality but rebased on the refactoring changes (Mercurial queues are useful!). You may observe that it integrates more cleanly with SimpleLibrary when building the installed configuration from storage as there is no need for an explicit "initialization" step to calculate the optimal service look up state.


Next steps
--------------

- The test class _Configuration (and associated test builder classes) need to updated to support the building of contexts with service information and new tests need to be added verify service provider module dependency resolution. This may be an opportunity to see if TestNG can be used?

- Retain topological order (from resolver's depth first search) for modules, contexts and service state. Iteration order of entries for HashMap and HashSet are not guaranteed if even it has up to now been mostly stable. The hash code related fixes in JDK8 will change that. Thus we need to explicitly support a consistent ordering using LinkedHashMap and LinkedHashSet. This is also the point at which to optimize the copying of state when building and constructing the configuration and contexts (i want persistent collections like those in Clojure and Scala!).

Paul.