RFR 8064924: Update java.net.URL to work with modules

[Peter Levart]

Hi Alan,

On 01/31/2015 10:33 PM, Alan Bateman wrote:
> On 31/01/2015 19:42, Peter Levart wrote:
>> Hi Chris,
>>
>> I looked at your solution to make URLStreamHandlerFactory interface a 
>> service provider using ServiceLoader API and in addition adding new 
>> URL static method to programmaticaly register  
>> URLStreamHandlerFactories. There are a couple of issues with your 
>> approach I'd like to discuss.
>>
>> The programmatic approach using static URL method does give you some 
>> means of order in which registered URLStreamHandlerFactories are 
>> tried to create URLStreamHandler for particular protocol - the 
>> registration order. It means that this method should only be called 
>> by one "party" in the VM or else it is hard to control the order of 
>> registration.
>>
>> ServiceLoader is a declarative approach, but does not give you order 
>> by default. Also, your ServiceLoader approach gives a way for 
>> URLStreamHandlerFactories to register in the system without security 
>> checks. If a particular 
>> META-INF/services/java.net.URLStreamHandlerFactory is found, it's 
>> content is used to load a class and instantiate a factory which is 
>> used in URL constructors then. Previously, one had to have a 
>> "setFactory" permission to set the URLStreamHandlerFactory or 
>> appropriate PropertyPermission for seting the package prefix 
>> property. This can be fixed.
>>
>> :
>>
>> Anyway, I think there is an alternative to programmatic registration 
>> approach of URLStreamHandlerFactories. Using just ServiceLoader and a 
>> new default method on URLStreamHandlerFactory interface to provide 
>> order. Here's what I'm thinking about:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.01/
>
> I don't think we should we expose ordering values in 
> URLStreamHandlerFactory, it looks a bit odd and not clear how an 
> implementation can choose a useful value. There is a general issue 
> that ServiceLoader doesn't currently support a means to order service 
> providers but I think we can re-examine that when we move to modules 
> and and linking. That is, have a consistent way to configure ordering 
> that we can use everywhere that ServiceLoader is used rather than 
> doing one-off solutions.

I agree. Putting the order on the SPI API is not the right solution. The 
order should be configured in one place. But there needs to be some kind 
of handle each service exposes for order configuration to reference. So 
one idea how to extend the ServiceLoader mechanism is this:

create a special class-scope runtime annotation...

public @interface ServiceProvider {
         String name();
}

...with which service implementation classes can optionally be 
annotated. This could enable ServiceLoader API extension like:

     public static <S> ServiceLoader<S> load(Class<S> service, String 
serviceProviderName)

that would return an Iterable over implementations that are annotated 
with a particular @ServiceProvider(name = ...) annotation (similar to 
security Providers but simpler).

In addition one could specify a system property with the key being 
prefixed by service interface FQ class name, like:

java.net.URLStreamHandlerFactory.serviceLoaderOrder=providerName1,providerName2,providerName3,...



>
> The other thing is that it's not clear how this would work for a 
> factory for the jar protocol that is itself deployed in a JAR file on 
> the class path. This is important for containers that want to do their 
> own caching and they want their jar protocol handler configured 
> system-wide before starting any applications. It's also part of the 
> motive for the addURLStreamHandlerFactory in the original proposal.

I see. But isn't URL.setURLStreamHandlerFactory() enough for that 
purpose? It can only be set once, but there can only be *one* container 
that wants it's jar protocol handler configured system-wide.

Regards, Peter

>
> I think you have good point with the setFactory permission, that does 
> need to be looked at.
>
> -Alan.