Dump services webrev

[Paul Sandoz]

On May 25, 2012, at 12:35 PM, Alan Bateman wrote:

> On 25/05/2012 09:45, Paul Sandoz wrote:
>> 
>> Hi,
>> 
>> See the following for a webrev to dump the services configuration:
>> 
>>   http://cr.openjdk.java.net/~psandoz/jigsaw/dump-services/webrev/
>> 
>> There is also some other minor stuff sneaking into this web rev related to services in general.
>> 
>> Paul.
> The update to the dump-config to print the services configurations looks fine to me, and very useful.
> 

Thanks.


> I don't know if you wanted comments on the "minor stuff" that sneaked in but here goes ...
> 

Of course!


> The change to jdk.depconfig is the beginnings of allowing jconsole have plugins installed as modules but there is more to do, as per the comments you've added to JConsole. My take on this is that -pluginpath isn't really compatible with modules and as jconsole is close to retirement (my words, but it is essentially replaced by VisualVM) then maybe the right thing is to just have jconsole run in -Xmode:legacy mode. Mandy?
> 

Yes, i put it in there as a reminder and because that is about as far as i could take it without further input. Remove the declaration?


> The change to HttpServerProvider.java is fine but it reminds me that it we have many places in the JDK where you can set a property to select the provider, and if not set then it fallbacks to looking for a service provider.

And them if service providers are present the first one is selected, otherwise if no service providers are present the default (non-reigstered) provider is used.


> It's come up on discussions here before too. Clearly setting the property to some implementation type that is not visible isn't going to work. However as the service providers will be installed as modules then the property mechanism could potentially be used to choose the provider. So in this case if com.sun.net.httpserver.HttpServerProvider is set to the name of a provider then we could use ServiceLoader to iterate through the providers to fine one with this name.
> 

I can see why that might be useful, but i find the use of system properties rather hacky, in this context it's seems like out of band information of an application.

If there was a way that an entry point could also make a preference on services providers that could formalize things a little better. 

Also, as we have discussed there are a class of services that are factories. Sometimes it is OK to have more than one present with selection of one loosely defined, other times it only makes sense to have at most one and a configuration error could result (e.g. multiple vendor implementations).

If we could change "requires service" to, for example "@Factory requires service" or 'requires factory", then it opens up the possibility to output warnings and errors.


> We should check with Phil Race about the sun.java2d.renderer property but I suspect these rendering engines will all be in the desktop module anyway. This is what is in jdk.desktop's module-info now:
> 
>     requires optional service sun.java2d.pipe.RenderingEngine;
>     provides service sun.java2d.pipe.RenderingEngine with sun.java2d.jules.JulesRenderingEngine;
>     provides service sun.java2d.pipe.RenderingEngine with sun.java2d.pisces.PiscesRenderingEngine;
> 
> Like the HttpServerProvider example it may be that the property is just used to select the service implementation.
> 

I will follow up with Phil.

Paul.