RFR 8064924: Update java.net.URL to work with modules

[Alan Bateman]

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.