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

[Bernd]

Hello,

What about simply rejecting overlapping programmatic registrations, and for
the service loader using the natural order (class loader search order). I
guess most extensions register new schemes only, as it was not easy before
in such a central shared system component. an ordering api might not really
help. Its might be better to allow specific versions like a factory or even
something thread local? (Similar to jndi enc)

Bernd
Am 01.02.2015 00:48 schrieb "Peter Levart" <peter.levart at gmail.com>:

>  Hi Alan,
>
> On 01/31/2015 10:33 PM, Alan Bateman wrote:
>
> 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.
>
>
> I agree. Putting the order on the SPI API is not the right solution. The
> order should be configured in one place. But there needs to be some kind of
> handle each service exposes for order configuration to reference. So one
> idea how to extend the ServiceLoader mechanism is this:
>
> create a special class-scope runtime annotation...
>
> public @interface ServiceProvider {
>         String name();
> }
>
> ...with which service implementation classes can optionally be annotated.
> This could enable ServiceLoader API extension like:
>
>     public static <S> ServiceLoader<S> load(Class<S> service, String
> serviceProviderName)
>
> that would return an Iterable over implementations that are annotated with
> a particular @ServiceProvider(name = ...) annotation (similar to security
> Providers but simpler).
>
> In addition one could specify a system property with the key being
> prefixed by service interface FQ class name, like:
>
>
> java.net.URLStreamHandlerFactory.serviceLoaderOrder=providerName1,providerName2,providerName3,...
>
>
>
>
> 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 see. But isn't URL.setURLStreamHandlerFactory() enough for that purpose?
> It can only be set once, but there can only be *one* container that wants
> it's jar protocol handler configured system-wide.
>
> Regards, Peter
>
>
> I think you have good point with the setFactory permission, that does need
> to be looked at.
>
> -Alan.
>
>
>