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

[Peter Levart]

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