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

[Chris Hegarty]

Thank you for the comments Alan.

On 06/02/15 10:20, Alan Bateman wrote:
> On 04/02/2015 15:11, Chris Hegarty wrote:
>> Agreed. Updated in-place
>>
>> http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
>>
> I think the approach and naming is good. A few small comments on the
> wording:
>
> 1. "used to locate URLStreamHandlerProvider providers" - the wording
> hints as further redirection, maybe it would be better as
> "URLStreamHandlerProvider implementations".

Updated. ( result of previous refactoring )

> 2. "the ordering that providers are located" - maybe this should be "the
> order that providers are located".

Updated. Thanks

> 3. "Some protocol, that are fundamental ...". Here's a re-worded
> statement to consider:
>
> "Some protocol handlers, for example those used for loading platform
> classes or classes on the class path, may not be overridden. The details
> of such restrictions, and when those restrictions apply (during
> initialization of the runtime for example), are implementation specific
> and therefore not specified".

This is better. Updated.

> One other thing in this area is setURLStreamHandlerFactory(null). Long
> standing behavior is to remove the system-wide URLStreamHandlerFactory,
> should this continue?

setURLStreamHandlerFactory can be called many times with 'null', but 
once it is called with a non-null arg then it can never be called again 
( it will throw ).

What I found was that code setting the pkg prefix property would call 
setURLStreamHandlerFactory(null) to clear the protocol handlers cache, 
and subsequent lookups would then consult the updated property. This is 
really only interesting if you plan to override existing protocols, and 
appears benign.

I have not changed this in the latest webrev. It seems like a corner 
case, and could be argued either way. The spec is less than clear about 
the expected behavior of this method when you pass it null.

Updated webrev [ spec and implementation] :
   http://cr.openjdk.java.net/~chegar/8064924/04/

Regarding jaxws, I suspect that I can simply reverse the changes in the 
webrev, and do nothing. Running on pre-JDK9 the property will continue 
to be set and used, on JDK9 and later the property will be set but 
ignored. I don't see that it is necessary anyway. Looks like technical 
debt. I'll file a separate issue for Miran to follow up and verify this.

-Chris.

>
> -Alan