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
