Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes
On 09/04/2014 22:19, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8039470/02/webrev/ That, that is easier to see the changes. In URL then it's not clear to me why the javadoc has to admit to a "system default package". Would it make sense to change this to just say that it falls back to using a built-in protocol handler if it is available? I also wonder about the wording in ContentHandler. For the sentence starting with "By default it looks in ..." then I wonder if it would make sense to re-word this so that it deals with the java.content.handler.pkgs property first and just say that if this is not defined then it falls back to using a built-in content handler if it exists. The latter could be placed after the section on the package structure and would make it clear that this package structure is only specified for the case that the property is set. -Alan.
Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes
On 10 Apr 2014, at 08:36, Alan Bateman wrote: > On 09/04/2014 22:19, Chris Hegarty wrote: >> >> http://cr.openjdk.java.net/~chegar/8039470/02/webrev/ > That, that is easier to see the changes. > > In URL then it's not clear to me why the javadoc has to admit to a "system > default package". Would it make sense to change this to just say that it > falls back to using a built-in protocol handler if it is available? Yes, possibly. > I also wonder about the wording in ContentHandler. For the sentence starting > with "By default it looks in ..." then I wonder if it would make sense to > re-word this so that it deals with the java.content.handler.pkgs property > first and just say that if this is not defined then it falls back to using a > built-in content handler if it exists. The latter could be placed after the > section on the package structure and would make it clear that this package > structure is only specified for the case that the property is set. I don’t know the original intent of over specifying here. It seems to be a case of the implementation making its way into the specification. Or possibly the intent was to support handlers being added to the bootclasspath. I’m not sure, but either way this whole area is legacy now. Let me take another look and see what can be done. -Chris. > > -Alan.
[8u-dev] RFR: 8036979: Support java.net.SocketOption<> in java.net socket types
Hi, This is the webrev for the 8u20 version of the fix that was reviewed yesterday for 9. JDK === http://cr.openjdk.java.net/~michaelm/8036979.8u20/jdk/01/webrev/ Top repo = http://cr.openjdk.java.net/~michaelm/8036979.8u20/top/01/webrev/ The good news is that the change is almost the same as the JDK 9 version with the following differences: 1) The java.net public API changes are gone. The new public methods for 9 in SocketImpl and DatagramSocketImpl are package private here. 2) A new package private class java.net.SocketsUtil acts as a bridge between the public API in jdk.net.Sockets and the implementation in java.net 3) jdk.net.Sockets uses reflection to access the methods of java.net.SocketsUtil 4) The test of the public java.net API is gone and the other test augmented with some additional tests for the standard socket options Thanks, Michael
