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

[Alan Bateman]

On 01/02/2015 10:45, Peter Levart wrote:
> :
>
> 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?

The legacy mechanism isn't going to work with modules as currently 
envisaged (the protocol handler factory class may be visible and be a 
public type but it doesn't mean that it will accessible when we have 
module boundaries). The intention is that ServiceLoader will work with 
modules and so it should be possible to deploy modules that provide 
implementations of URLStreamHandlerFactory.

> :
>
> 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

Applications using setURLStreamHandlerFactory expect their protocol 
handler factory to be used and we don't want to break this. So I think 
this has to be called first, the only exception is the core protocols 
(file and jrt mostly) that cannot be overridden. So in your order then I 
think #2 and #3 should be reserved.

-Alan