Just catching up… On 2 Feb 2015, at 08:42, Alan Bateman <alan.bate...@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
