Services/configuration/context webrevs

[Paul Sandoz]

Hi Mandy,

On Aug 8, 2012, at 2:55 AM, Mandy Chung <mandy.chung at oracle.com> wrote:

> Paul,
> 
> On 7/1/2012 2:34 AM, Paul Sandoz wrote:
> 
>> Service state on configuration
>> ----------------------------------------
>> 
>> http://cr.openjdk.java.net/~psandoz/jigsaw/config-services/webrev/
> 
> Sorry for the delay on getting to this one.
> 
> This change keeps a global map of service interface to its service
> provider class names in the configuration for a more efficient service
> lookup and service instance creation at runtime which is good.
> 

Yes, plus it does not expose the Map, it only exposes the look up using Iterable given a service interface class, thus allowing more flexibility of the implementation.


> On the other hand, I'm not sure about the new InstalledConfiguration
> class, an extension to Configuration.  While service lookup is only
> needed at runtime, it seems to me that Configuration<PathContext>  would
> be the subclass of Configuration rather than Configuration<Context>.

There is currently no additional functionality specific to Configuration<PathContext> that a subtype is required for that.


> With modulepath, there isn't any installed configuration that some
> refactoring might be needed.  

Are you referring to the potential execution from compiled exploded modules?

If so, there are still services present, so it will still likely be the same as Configuration<Context> and using  org.openjdk.jigsaw.Linker, where the storage is abstracted using a special Library implementation to handle the exploded layout of modules and class files [*]. AND, it does not negate caching/storing the configuration on disk if we know that nothing has changed for a subsequent execution.

If not, InstalledConfiguration is never referenced for compile-time related functionality. PathContext holds no service-related information and thus PathLinker does not manipulate such information.

--

Note that potentially we may in the future control the iteration order of service provider classes i.e. the order which they are stored in the configuration, so the InstalledConfiguration may require further functionality/persistence to adjust the order.


> There will be some API refactoring/cleanup
> anyway (as you have already attempted).

And... :-) When should that occur, and who is gonna do it?


>  I wonder if this patch can simply
> define the Configuration.findServices method that might well be an
> abstract method implemented by the InstalledConfiguration class
> which will only be an implementation class used by StoredConfiguration.
> 

IMHO that is breaking the abstraction since service provider modules are not linked at compile time.

What would be the implementation of Configuration.findServices for a type of Configuration<PathContext>?

--

I did not want to mess around with StoredConfiguration knowing that it will change. Currently it needs to use the same type for reading/writing (as per the abstraction StoredConfiguration extends from).

FWIW this was the "purest" abstraction i could think of without doing further refactoring [1], so i think we should reconsider abstracting run-time and install-time configuration, if it makes sense, as part of a larger refactoring effort, or as part of other patches if it makes sense within that context.

Maybe renaming to RunAndInstallConfiguration would help?

Paul.

[*] Javac does a similar trick with Configuration<PathContext> and a special implementation of Catalog, com.sun.tools.javac.jigsaw.JavacCatalog.

[1] I also wanted to avoid pushing this explicitly into the runtime, say in LoaderPool, as the implementation of the Iterable could change over time depending on how things are stored/ordered etc.