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
