On 02/01/2015 10:56 AM, Alan Bateman wrote:
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.
This a good question as it brings up the scenario that Chris is trying
to address by introducing addURLStreamHandlerFactory. The concern is
where the container starts an application that also uses the legacy
setURLStreamHandlerFactory. The container is trying not to cause the
application to fail with an error. Looking at it again then I think
addURLStreamHandlerFactory is going to be more an attractive nuisance
that expected, despite the @apiNote and we need to drop this part of
the solution. There are compatibility and migration concerns but I
don't think they are significant in the overall context of a major
release.
-Alan
Here's another idea:
If URLStreamHandlerFactories could (optionally) announce supported
protocols, then existing method setURLStreamHandlerFactory could allow
setting multiple factories as long as they don't conflict. A container
could set a factory that announces "jar" protocol only and that would
not conflict with application deployed in container setting an
URLStreamHandlerFactory that doesn't announce anything, so will be
called for anything but "jar" in this situation.
Here's what I mean:
http://cr.openjdk.java.net/~plevart/jdk9-dev/URLStreamHandlerFactory/webrev.02/
Regards, Peter
