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

[Peter Levart]

On 02/01/2015 10:56 AM, Alan Bateman wrote:
> On 31/01/2015 23:47, Peter Levart wrote:
>>
>> 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:
> I think this is a much bigger topic and one that the URL usage isn't 
> one of the better examples to explore it (the reason being that 
> providers of URLStreamHandlerFactory are proposed to only be located 
> via the system class loader, no proposal to allow for bundling with an 
> application which is where the real scope issues come to the fore).

I see. But if URLStreamHandlerFactories are only supposed to be located 
via the system class loader, is that different from what we have now 
when URLStreamHandlers are being located directly via class name 
construction (prefix + protocol + .Handler) and loaded via the system 
class loader? They have to be public classes with public default 
constructors, yes. But so have to be URLStreamHandlerFactories too, to 
be loadable by ServiceLoader.

Are we just trying to get rid of old mechanism or is there something I'm 
missing?

>
>
>>
>> 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.
>>
> This a good question as it brings up the scenario that Chris is trying 
> to address by introducing addURLStreamHandlerFactory. The concern is 
> where the container starts an application that also uses the legacy 
> setURLStreamHandlerFactory. The container is trying not to cause the 
> application to fail with an error. Looking at it again then I think 
> addURLStreamHandlerFactory is going to be more an attractive nuisance 
> that expected, despite the @apiNote and we need to drop this part of 
> the solution. There are compatibility and migration concerns but I 
> don't think they are significant in the overall context of a major 
> release.

If that's the reason for addURLStreamHandlerFactory (to support apps 
deployed to containers and which use setURLStreamHandlerFactory) then 
there should probably be some mechanism to allow those apps to call 
setURLStreamHandlerFactory but don't allow them to override handlers for 
protocols that container is trying to enforce (like jar). So factory set 
by setURLStreamHandlerFactory should not be evaluated 1st. What about 
the following order of evaluation:

1. default system factory if protocols are "file" or "jrt"
2. factories registered via ServiceLoader or addURLStreamHandlerFactory 
or equivalent
3. factory set by setURLStreamHandlerFactory if any
4. default system factory


Peter

> -Alan