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

[Chris Hegarty]

Just catching up…

On 2 Feb 2015, at 08:42, Alan Bateman <Alan.Bateman at oracle.com> wrote:

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

Thanks Alan. This may not have been clear from my original mail.

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

Right, and if you reverse #2 and #3 above, you get the same ordering as in the original proposal.  I deliberately avoided any behavioural changes with setURLStreamHandlerFactory.

I hope I have not missed other comments ( please send them again, if they have not already been addressed ), but I think the only outstanding issue, with regard to the spec changes, is the permission on addURLStreamHandlerFactory. Maybe this method should define a new permission, rather than reusing setFactory, it could be RuntimePermission(“addFactory”). It would help further differentiate the addURLSHF and setURLSHF methods.

-Chris.

> -Alan