Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Chris Hegarty
On 8 Apr 2014, at 13:50, Chris Hegarty wrote: > On 8 Apr 2014, at 12:12, Alan Bateman wrote: > >> Chris, >> >> One thing to avoid consider is the ContentHandler javadoc. It contains this: >> >> " By default it looks in sun.net.www.content, ..." >> >> but this is JDK-specific location and s

RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

2014-04-08 Thread Chris Hegarty
java.net.URLConnection.getContent() incorrectly specifies the default location of content handler classes as sun.net.www.content. ( this location is implementation specific ) "If no content handler factory has yet been set up, or if the factory's createContentHandler method returns null

RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

2014-04-08 Thread Michael McMahon
Could I get the following reviewed please? In addition to providing generic support for java.net.SocketOption, it also includes 8032808, which implements a platform specific socket option SO_FLOW_SLA (in jdk.net) There are changes to two repos: http://cr.openjdk.java.net/~michaelm/8036979/jdk/0

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Mandy Chung
On 4/8/2014 6:15 AM, Chris Hegarty wrote: Updated webrev to include Mandy’s and Alan’s comments: http://cr.openjdk.java.net/~chegar/8039362/02/webrev/ Thanks for the update. line 238: I wonder if this should fall back to use the default built-in table - really minor one as this happens

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Chris Hegarty
Updated webrev to include Mandy’s and Alan’s comments: http://cr.openjdk.java.net/~chegar/8039362/02/webrev/ On 7 Apr 2014, at 22:50, Mandy Chung wrote: > …. > > line 225: since content-types.properties is moved to the same package as > MimeType class, you can simply use the relative path

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Alan Bateman
On 08/04/2014 13:50, Chris Hegarty wrote: : Yes, this is a legacy bug. It is related to the location of specific content type handlers, and as such a separate issue. I would like to handle it separately so as not to confuse the changes being proposed for this 8039362. I’ll file a new JIRA bug

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Chris Hegarty
On 8 Apr 2014, at 12:12, Alan Bateman wrote: > Chris, > > One thing to avoid consider is the ContentHandler javadoc. It contains this: > >" By default it looks in sun.net.www.content, ..." > > but this is JDK-specific location and so shouldn't be in the javadoc. Yes, this is a legacy bug.

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Alan Bateman
Chris, One thing to avoid consider is the ContentHandler javadoc. It contains this: " By default it looks in sun.net.www.content, ..." but this is JDK-specific location and so shouldn't be in the javadoc. -Alan.

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Alan Bateman
On 07/04/2014 19:54, Chris Hegarty wrote: [ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ] Hi Erik, thanks for your feedback, comments inline… Updated webrev: http://cr.openjdk.java.net/~chegar/8039362/01/webrev/ Looks like JDK-71537

Re: RFR [9] 8039362: Read content-types.properties as a resource

2014-04-08 Thread Erik Joelsson
Hello Chris, Build part looks good to me now. /Erik On 2014-04-07 20:54, Chris Hegarty wrote: [ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ] Hi Erik, thanks for your feedback, comments inline… Updated webrev: http://cr.openjdk.j