On 31/01/2015 19:42, Peter Levart wrote:
Hi Chris,
I looked at your solution to make URLStreamHandlerFactory interface a
service provider using ServiceLoader API and in addition adding new
URL static method to programmaticaly register
URLStreamHandlerFactories. There are a couple of issues with your
approach I'd like to discuss.
The programmatic approach using static URL method does give you some
means of order in which registered URLStreamHandlerFactories are tried
to create URLStreamHandler for particular protocol - the registration
order. It means that this method should only be called by one "party"
in the VM or else it is hard to control the order of registration.
ServiceLoader is a declarative approach, but does not give you order
by default. Also, your ServiceLoader approach gives a way for
URLStreamHandlerFactories to register in the system without security
checks. If a particular
META-INF/services/java.net.URLStreamHandlerFactory is found, it's
content is used to load a class and instantiate a factory which is
used in URL constructors then. Previously, one had to have a
"setFactory" permission to set the URLStreamHandlerFactory or
appropriate PropertyPermission for seting the package prefix property.
This can be fixed.
:
Anyway, I think there is an alternative to programmatic registration
approach of URLStreamHandlerFactories. Using just ServiceLoader and a
new default method on URLStreamHandlerFactory interface to provide
order. Here's what I'm thinking about:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.01/
I don't think we should we expose ordering values in
URLStreamHandlerFactory, it looks a bit odd and not clear how an
implementation can choose a useful value. There is a general issue that
ServiceLoader doesn't currently support a means to order service
providers but I think we can re-examine that when we move to modules and
and linking. That is, have a consistent way to configure ordering that
we can use everywhere that ServiceLoader is used rather than doing
one-off solutions.
The other thing is that it's not clear how this would work for a factory
for the jar protocol that is itself deployed in a JAR file on the class
path. This is important for containers that want to do their own caching
and they want their jar protocol handler configured system-wide before
starting any applications. It's also part of the motive for the
addURLStreamHandlerFactory in the original proposal.
I think you have good point with the setFactory permission, that does
need to be looked at.
-Alan.
