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

Alan Bateman Alan.Bateman at oracle.com
Fri Jan 30 14:32:37 UTC 2015


On 30/01/2015 13:36, Chris Hegarty wrote:
> This is phase 1, of getting java.net.URL work with modules.
>
> Being able to effectively specify URL protocol handler factories as fully qualified class names, through the 'java.protocol.handler.pkgs' system property is problematic. It requires the protocol handler factory implementation class to be public and accessible, as the current implementation tries to instantiate it through core reflection. Since the protocol handler factory must be an implementation of a URLStreamHandlerFactory, it lends itself to being retrofitted with a ServiceLoader lookup. Note, the 'java.protocol.handler.pkgs' system property mechanism predates ServiceLoader. URL protocol handlers would most likely have used service loader if it were available at the time.
>
> Some URL protocol handlers are fundamental to the platform itself, like 'file' and 'jar', it is not appropriate to attempt a service loader lookup for these, as they may lead to recursive initialization issues. However, Java Plugin, Webstart, and possibly other containers, do override the 'jar' handler. A new API will be provided for this purpose. Providing an API solution should not interfere with system initialization as it will only be called after the system comes up and user code is executing.
>
> The 'file' protocol handler factory will no longer be overridable, and the system property will no longer be consulted.
>
> Webrev and spec diffs:
>    http://cr.openjdk.java.net/~chegar/8064924/00/
>
> I want to agree the approach and spec first, so that the spec changes can be submitted for approval. A comprehensive test will be added before the code changes are finalised.
>
>
I've had a number of off-list discussions with Chris on this and I think 
the proposal and the ordering is good. It preserves behavior for those 
setting the system-wide URLStreamHandlerFactory with 
setURLStreamHandlerFactory and only really creates a migration issue for 
those setting the JDK 1.0/1.1 era pkgs property property.

One thing that I wasn't aware of is the hairy in SAAJ. That is some 
thing that will need to coordinated with upstream and hopefully Miroslav 
can help on that. As upstream might still have a constraint that the 
code compile with JDK 7 and JDK 8 then some adjustments might be required.

In any, the focus now is agreeing the API changes before digging into 
the code changes.

I've read through the javadoc and it looks good. A couple of suggestions:

- step 2: alternative wording: "The createURLStreamHandler method of 
each factory is invoked, in registration order, with the protocol 
string, until a factory returns non-null".

- step 3: "ServiceLoader mechanism is used" might be better than 
"ServiceLoader mechanism tries".

- step 3: "ServiceConfigurationErrors", maybe this should be singular as 
the first will cause the search to bail. Related to this is 
createURLStreamHandler terminating with an error or runtime exception, 
you may want to mention that too.

In the @apiNote in addURLStreamHandlerFactory then "containers" might 
not be understood by the reader. I don't have an alternative but maybe 
make it clear that this is for system-wide configuration and not 
intended to be used by transient applications.

-Alan





More information about the core-libs-dev mailing list