I agree with Alan, addURLStreamHandlerFactory is probably an attractive
nuisance. It is not strictly necessary to achieve the goal here; replace
the problematic ( with modules ) system property with a service lookup.
For now, I'd like to move this issue forward without the additional new
public method. We can have deploy use setURLSHF(), and document the
compatibility issue if applets/Webstart apps also try to set a factory.
We can revisit this later in 9, if it becomes an issue.
Updated specdiff:
http://cr.openjdk.java.net/~chegar/8064924/02/specdiff/
I this revision, I omitted the implementation changes, so we can agree
the spec changes first. They are much simpler now.
-Chris.
On 02/02/15 09:15, Chris Hegarty wrote:
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
