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.

Reply via email to