Dump services webrev

Alan Bateman Alan.Bateman at oracle.com
Fri May 25 10:43:21 PDT 2012


On 25/05/2012 17:02, Jesse Glick wrote:
> On 05/25/2012 06:35 AM, Alan Bateman wrote:
>> if com.sun.net.httpserver.HttpServerProvider is set to the name of a 
>> provider then we could use ServiceLoader to iterate through the 
>> providers
>
> Another possibility would be for ServiceLoader to check for a system 
> property with the same (binary) name as the service; if set, and 
> corresponding to the (binary) name of one of the providers, load that 
> one and that one only. Would offer an easy compatibility path for some 
> legacy code. But maybe this should be left to the caller to handle.
I would leave this to the caller as it will be usage specific as to 
whether it wants to specify/support an override mechanism. Also there 
may be cases where the system property is different. As it happens the 
RenderingEngine is one such case as the property is sun.java2d.renderer 
rather than sun.java2d.pipe.RenderingEngine.

>
>> 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;
>
> If a module provides the service it requires (in fact provides two 
> variants), surely the "optional" keyword is unnecessary?
I think this you are right, or at least you will be right if the 
property override is changed.

>
> Same in NetBeans; logs a warning and continues with no impact on the 
> caller. Catching ServiceConfigurationError in each caller would be be 
> a pain, and since it is unchecked it would be easily forgotten, and if 
> forgotten it is unlikely to be noticed during development and come up 
> only in production systems. In Jigsaw the module system should catch 
> most potential problems (e.g. misspelled service name) statically, but 
> the service constructor/factory could still throw an exception I suppose.
For Java SE then many APIs specify if/how fail if the instantiation of 
the provider fails. Exactly how they fail is a bit inconsistent. As 
examples JAXP defines various *ConfigurationExceptions, NIO is more low 
level and will throw an unspecified error, and there are others. So I 
think the right thing it to leave it up to the caller to specify how it 
behaves in this case, meaning I don't think ServiceLoader should use 
logging or emit warnings.

-Alan.




More information about the jigsaw-dev mailing list