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

[Alan Bateman]

On 31/01/2015 23:47, Peter Levart wrote:
>
> 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:
I think this is a much bigger topic and one that the URL usage isn't one 
of the better examples to explore it (the reason being that providers of 
URLStreamHandlerFactory are proposed to only be located via the system 
class loader, no proposal to allow for bundling with an application 
which is where the real scope issues come to the fore).


>
> 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