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
