Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

Hi Dimitar, Thank you for following up with this. I came to the same conclusion as you earlier today, though I noticed it because the test SocksServer was sending a single byte at a time, for the initial reply. I took your latest patch and applied a few minor cleanups, as follows: http://t4.i

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

On 13 Jan 2014, at 19:29, Chris Hegarty wrote: > On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: > >> Hi Chris, >> >> I can't open the link, but yet I wouldn't mind if you folded your patch into >> mine. > > How embarrassing. Our public fa

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

On 14 Jan 2014, at 10:51, Alan Bateman wrote: > On 14/01/2014 08:28, Chris Hegarty wrote: >> On 13 Jan 2014, at 19:29, Chris Hegarty wrote: >> >>> On 13 Jan 2014, at 19:23, Dimitar Mavrodiev wrote: >>> >>>> Hi Chris, >>>> >>

Re: RFR: 7100957 : Java doesn't correctly handle the SOCKS protocol when used over IPv6

On 14 Jan 2014, at 10:53, Chris Hegarty wrote: > On 14 Jan 2014, at 10:51, Alan Bateman wrote: > >> On 14/01/2014 08:28, Chris Hegarty wrote: >>> On 13 Jan 2014, at 19:29, Chris Hegarty wrote: >>> >>>> On 13 Jan 2014, at 19:23, Dimitar Mavrodiev w

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

The bug shows the following stacktrace: --System.err:(16/903)-- java.net.SocketTimeoutException: Receive timed out at java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native Method) at java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramS

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

On 17/01/14 10:39, Tristan Yan wrote: Agree, reset timeout should be better move http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Thanks, approved. I can sponsor this change for you. -Chris. Thank you Tristan On 01/17/2014 06:32 PM, Chris Hegarty wrote: The bug shows the following

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

On 17/01/14 10:48, Chris Hegarty wrote: On 17/01/14 10:39, Tristan Yan wrote: Agree, reset timeout should be better move http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Oh, we should really increase the acceptable expected time in the subsequent checkTime call. From say 2000 -> 4

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

time, 2000 -> 4000, should be sufficient. -Chris. Thank you Tristan On 01/17/2014 07:20 PM, Chris Hegarty wrote: Oh, we should really increase the acceptable expected time in the subsequent checkTime call. From say 2000 -> 4000. If you agree, I will make the change before pushing on your behalf.

Re: AES GCM slow

Cross posting to security-dev, since the question cipher related. -Chris. On 27/01/14 09:28, Mark Christiaens wrote: I wrote a little test client/server setup that transfers 100 MB of data over an SSL socket configured to use TLS 1.2 AES GCM (TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256). On my i7-

RFR [9] 7150539: HttpURLConnection.getResponseMessage() doesn't throw IOException on server error (OS X)

This is a trivial test only change to make it agnostic of system proxy setting on OS X. The test requires that it makes a direct connection to the self contained trivial test HTTP server, it should not be influenced by system proxy settings. diff --git a/test/sun/net/www/http/HttpClient/RetryP

Re: RFR: 8033425 Delay loading of net library in PortConfig initialization (workaround for for 8033367)

Looks ok to me Michael. -Chris. On 03/02/14 14:04, Michael McMahon wrote: Could I get this change reviewed for JDK 8 please? http://cr.openjdk.java.net/~michaelm/8033425/webrev.1/ The problem affects appletviewer, but it doesn't seem to be reproducible with the applet support in jtreg. So, he

RFR [9] Inet[4|6]Address class and fieldID initialization in networking native code

Hi, This change is mainly about clean up of the networking native code. There are a number of places that cache JNI global references to the Inet[4|6]Address classes, as well as caching their respective field IDs. It is also difficult to correctly handle propagation of possible JNI method inv

Re: RFR [9] Inet[4|6]Address class and fieldID initialization in networking native code

And a link to the webrev that can people can access: http://cr.openjdk.java.net/~chegar/nativeInetCleanup/webrev/ -Chris. On 02/04/2014 04:01 PM, Chris Hegarty wrote: Hi, This change is mainly about clean up of the networking native code. There are a number of places that cache JNI global

RFR (XS) [9] PlainDatagramSocketImpl missing returns after “throwing an exception”

Some very minor clean up in PlainDatagramSocketImpl to add some missing returns after “throwing an exception”, as well as checking for a pending exception after calling setTTL ( that can throw ). http://cr.openjdk.java.net/~chegar/nativeInetCleanup/webrev.02/webrev/src/solaris/native/java/net/Pl

Re: 8034182: Misc. warnings in java.net code

Thanks Alan, I appreciate the drive-by! The changes look good to me. -Chris. On 11 Feb 2014, at 13:13, Alan Bateman wrote: > > This is drive-by fix to a number of native code warnings in the networking > code. > > In NET_SockaddrToInetAddress then CHECK_NULL_RETURN is used to check the > re

Re: Remove support for old socket implementations

On 14/02/14 14:04, Alan Bateman wrote: On 14/02/2014 13:52, Florian Weimer wrote: This patch removes support for old, pre-1.4 SocketImpl and DatagramSocketImpl classes. Compiling these classes has been impossible since 1.4 because 1.4 added new abstract methods to the base classes. Is this oka

Re: Discussion on root cause analysis of JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently

Michael, I’m ok with your analysis, and suggested fix. From the original test output, in the bug description, I can see that there are 58 println’s with "Request from:" for test3, and two "Worker: Error writing to server”. This would tend to support your analysis that that server, in some cas

Re: RFR for JDK-7052625 : com/sun/net/httpserver/bugs/6725892/Test.java fails intermittently

On 20 Feb 2014, at 12:53, michael cui wrote: > On 02/20/2014 07:24 PM, Chris Hegarty wrote: >> Michael, >> >> I’m ok with your analysis, and suggested fix. >> >> From the original test output, in the bug description, I can see that there >> are 58 p

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

Mark, I agree with you, there is certainly some additional co-ordination needed between the thread invoking the stop method and the dispatcher thread. I wonder why you needed to add the selectNow() and the close() after you have joined the dispatcher thread? Since you are guaranteed that the di

RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

Interruptible I/O on Solaris has been highly problematic and the long standing plan has been to remove it from the JDK. In JDK6 the VM option UseVMInterruptibleIO was introduced to allow developers/customers experiment with disabling it. In JDK7 the default value of UseVMInterruptibleIO was cha

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

On 22 Feb 2014, at 09:33, Alan Bateman wrote: > On 22/02/2014 08:29, Chris Hegarty wrote: >> Interruptible I/O on Solaris has been highly problematic and the long >> standing plan has been to remove it from the JDK. In JDK6 the VM option >> UseVMInterruptibleIO wa

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

ges, desirable or otherwise, then they should come under a separate JIRA issue. -Chris. > > -Dmitry > > > On 2014-02-22 12:29, Chris Hegarty wrote: >> Interruptible I/O on Solaris has been highly problematic and the long >> standing plan has been to remove it from the J

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

Thanks for your comments Bernd. On 22 Feb 2014, at 14:03, Bernd Eckenfels wrote: > Hello, > >> Am 22.02.2014 um 10:33 schrieb Alan Bateman : >> >>> http://cr.openjdk.java.net/~chegar/8034174/webrev.00/webrev/ >> Thank for you for doing this, it's long over due. > > Hm, I actually like to have

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

On 24/02/14 10:42, Michael McMahon wrote: On 23/02/14 08:55, Chris Hegarty wrote: On 22 Feb 2014, at 17:23, Dmitry Samersoff wrote: Chris, Didn't look to windows part. Unix part looks good for me. See also below. I'm a bit concerned because of mixing NET_* abstractions and dire

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

On 24/02/14 14:12, Michael McMahon wrote: On 24/02/14 14:09, Chris Hegarty wrote: On 24/02/14 10:42, Michael McMahon wrote: On 23/02/14 08:55, Chris Hegarty wrote: On 22 Feb 2014, at 17:23, Dmitry Samersoff wrote: Chris, Didn't look to windows part. Unix part looks good for me. See

Re: RFR [9]: 8034174 Remove use of JVM_* functions from java.net code

Latest webrev: http://chhegar.ie.oracle.com/chhegar/repos/jdk9/dev/dev/jdk/8034174/webrev.01/webrev/ -Chris. On 24/02/14 14:12, Michael McMahon wrote: On 24/02/14 14:09, Chris Hegarty wrote: On 24/02/14 10:42, Michael McMahon wrote: On 23/02/14 08:55, Chris Hegarty wrote: On 22 Feb 2014

Re: RFR: JDK-8015692 - java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop.

for cleanup purposes. It is possible that the join should be higher up in the stop() flow i.e. immediately after the setting the finish flag? As such, the Dispatcher should be finished with the various HttpConnection collections, before the stop processes them. regards Mark On 21/02/2014 07:22, C

Re: RFR: 8035653: InetAddress.getLocalHost crash

Thanks for jumping on this Michael, one of my recent changes caused the problem. Your fix looks good to me. Trivially, the test has a 2006 copyright header. -Chris. On 24/02/14 17:55, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michael

Re: RFR : 7076487 : (sctp) SCTP API classes does not exist in JDK for Mac

Thanks Sean. Looks good to me. -Chris. On 26/02/14 15:45, Seán Coffey wrote: Looking to backport this one to jdk7u-dev. Given the different build system, the make logic is different. bug ID : https://bugs.openjdk.java.net/browse/JDK-7076487 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7

Re: RFR[9](XS): 8035876: AIX: Fix AIX build after '8034174: Remove use of JVM_* functions from java.net code'

On 26/02/2014 19:12, Alan Bateman wrote: On 26/02/2014 17:48, Volker Simonis wrote: : That said, '8034174: Remove use of JVM_* functions from java.net code' broke the AIX build and here's the small change which fixes it again: http://cr.openjdk.java.net/~simonis/webrevs/8035876/ https://bugs.o

Re: RFR for bug JDK-8035633 TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently

On 27 Feb 2014, at 08:18, Eric Wang wrote: >> ….. > > Thanks Alan to suggest the correct alias! > Below is the webrev for this bug, Can you or anyone else help to review the > fix? > http://cr.openjdk.java.net/~ewang/JDK-8035633/webrev.00/ >

Re: RFR[9](M): 8035949 : Remove unused macro USE_SELECT and clean up Unix version of net_util_md.{c,h}

Volker, The changes look fine to me, and in line with what I was thinking too. Quite trivially you can remove the block '{' from net_util_md.c Line 1637 and 1650. Also, the function comment says "Wrapper for select/poll ..." ( can remove 'select' ). I ran your patch through our internal buil

RFR [9] 8035897 : FD_SETSIZE should be set on macosx

[ Volker: there are some trivial AIX changes here, maybe you could verify them? ] JDK-8021820 adds -D_DARWIN_UNLIMITED_SELECT to the build, but the fd_set struct is still limited to 1024. Snippet from man select(2): "Although the provision of getdtablesize(2) was intended to allow user p

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

Thanks for looking at this Michael, comments inline... On 28/02/14 15:55, Michael McMahon wrote: ... I agree option 2 sounds better since adding (say) 4k * sizeof(fd_set) to the stack is quite significant given that it would rarely be required. Agreed. On the change itself I noticed one pat

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

On 28 Feb 2014, at 17:28, chris...@zoulas.com wrote: > On Feb 28, 3:55pm, michael.x.mcma...@oracle.com (Michael McMahon) wrote: > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx > > | On 28/02/14 14:40, Chris Hegarty wrote: > | > [ Volker: there ar

RFR [9] 8035868: Check for JNI pending exception in windows/native/sun/net/spi/DefaultProxySelector.c

Some more trivial checking in the Windows native code for JNI pending exceptions. http://cr.openjdk.java.net/~chegar/8035868/webrev.00/webrev/ -Chris.

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

> On 1 Mar 2014, at 01:27, chris...@zoulas.com wrote: > > On Feb 28, 5:41pm, chris.hega...@oracle.com (Chris Hegarty) wrote: > -- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx > > | We are using select on OS X, only, because of a bug in pol

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

don't proposed to change that in this issue. -Chris. On 02/03/14 19:44, Alan Bateman wrote: On 28/02/2014 14:40, Chris Hegarty wrote: : I think option 2 is preferable: http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/ I'm still checking to see it an automatic regression t

Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

On 4 Mar 2014, at 03:25, Ivan Gerasimov wrote: > Yes, you're right. > strtok() is thread-safe in Windows unlike its Unix counterpart. > > Thus using strtok_s() only adds some boundary checking in this case. Ivan, Are you now withdrawing this request for review? Or are you suggesting that st

Re: RFR: 8025293 - JNI exception pending checks in java.net

This looks good to me Mark. Trivially, and it is more of a stylistic preference, towards the end of the Solaris NetworkInterface.c I would remove the if (ob) … else, and use CHECK_NULL_RETURN(obj, NULL). But, what you have is right, either is fine. -Chris. On 4 Mar 2014, at 11:06, Mark Sheppar

Re: RFR: [8036088] - Thread-unsafe strtok() is used to parse

, even though > it adds only a little. > If you guys are OK with the fix, of course. The changes seem mostly benign to me. I have no objections to being listed as a reviewer. -Chris. > > Sincerely yours, > Ivan > > > On 04.03.2014 14:28, Chris Hegarty wrote:

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

On 5 Mar 2014, at 09:48, Eric Wang wrote: > Hi everyone, > > Hi Everyone, > > I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209, > The test uses Thread.sleep to sync-up threads which is not a correct > assumption. The fix is just to sync-up 2 threads using proper wa

Re: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends

Thanks for doing this Pavel. The changes, and test, look good to me. I can sponsor this for you. -Chris. On 19/03/14 18:03, Pavel Rappo wrote: Hi everyone, could you please review my change for JDK-8035158? DefaultProxySelector uses sun.misc.RegexpPool to parse properties that configure the

Re: RFR JDK-8035158: Remove dependency on sun.misc.RegexpPool and friends

Thanks for doing this Pavel. The changes, and test, look good to me. I can sponsor this for you. I assume that once this changes is pushed, JDK-8037781: "Remove sun.misc.Regexp* classes", can proceed. -Chris. On 19/03/14 18:03, Pavel Rappo wrote: Hi everyone, could you please review my cha

Re: RFR: JDK-8035631 - JNI exception pending in jdk/src/windows/native/java/net/NetworkInterface_winXP.c

This looks ok to me Mark. You have added a question/comment on L514. Is this intentional? L555. Not directly related to your changes, but should netaddrP be freed there before returning NULL? -Chris. On 14/03/14 19:04, Mark Sheppard wrote: Hi Please oblige and review the following chang

RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a SIBGUS on sparc(v9) if the address is not 4

Re: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

On 22 Mar 2014, at 08:19, Alan Bateman wrote: > On 22/03/2014 08:13, Chris Hegarty wrote: >> The native SCTP implementation assumes that the given byte buffer ( buffer >> address + position ) is memory aligned. It re-uses the buffer for handling >> notifications from the

Re: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

: On 22/03/2014 08:13, Chris Hegarty wrote: The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a

Re: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

On 24/03/14 16:17, Alan Bateman wrote: On 24/03/2014 14:09, Chris Hegarty wrote: Alan, Dmitry, I updated the webrev. It now allocates memory dynamically, and asserts that the number of bytes read is less than the size of sctp_notification ( for notifications ). http://cr.openjdk.java.net

Re: [9] Review request for 8032832: Applet/browser deadlocks, when IIS integrated authentication is used

Hi Anton, I don't have any objections to this, but Max is the original author of this code and may want to take a closer look. -Chris. On 20/03/14 14:08, Anton Litvinov wrote: Hello, Could you please review the following fix for the bug, which consists in a deadlock between 2 threads sharin

RFR [9] 8038459: (sctp) Remove superflous classes on platforms without an implementation [macosx, aix]

While hunting around the build recently, when working on another SCTP bug, I noticed a small issue where SCTP classes are being built on some platforms unnecessarily. Webrev: http://cr.openjdk.java.net/~chegar/8038459/webrev.00/webrev/ Mac OS X and AIX contain only stubs for the SCTP channels

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

w the fix below for bug JDK-8025209 <https://bugs.openjdk.java.net/browse/JDK-8025209>. The fix is just to make the thread synchronization is more robust and made some cleanup. http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/ Thanks, Eric On 2014/3/5 18:01, Chris Hegarty wrote: On 5

Re: RFR for JDK-8038276 java/net/NetworkInterface/Test.java fails on windows intermittently for Teredo Interface

Looks ok to me Amanda. I can sponsor this change, if needed. -Chris. On 28/03/14 05:07, Amanda Jiang wrote: Hi All , Please check and review following changes: http://cr.openjdk.java.net/~ewang/amanda/JDK-8038276/webrev.00/ Description of issue: Root Cause: Test java/net/NetworkInterface/Test

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/ Thanks to review the fix and sponsor it for me. -Eric On 2014/3/28 18:41, Chris Hegarty wrote: Hi Eric, I've taken a look at the webrev and I mainly agree with the changes/refactoring. On the issue of increasing the timeout to 20 secs; there is a clear

RFR [9] 8038821: Fix typo; consructed to constructed

Trivial typo fix. diff --git a/src/share/classes/java/net/HttpCookie.java b/src/share/classes/java/net/HttpCookie.java --- a/src/share/classes/java/net/HttpCookie.java +++ b/src/share/classes/java/net/HttpCookie.java @@ -74,7 +74,7 @@ private boolean httpOnly; // HttpOnly ... i.e. not ac

Re: RFR [9] 8038821: Fix typo; consructed to constructed

On 31.03.2014 17:42, Chris Hegarty wrote: Trivial typo fix. diff --git a/src/share/classes/java/net/HttpCookie.java b/src/share/classes/java/net/HttpCookie.java --- a/src/share/classes/java/net/HttpCookie.java +++ b/src/share/classes/java/net/HttpCookie.java @@ -74,7 +74,7 @@ private bo

Re: 8039253: Remove undocumented com.oracle.net

This looks fine to me. Thanks Alan. -Chris. On 04/04/14 12:31, Alan Bateman wrote: As part of our long standing effort to prepare the platform for modules then we need to go through the various JDK-specific APIs and see which APIs are really "exported", supported, documented, etc. One odd one

Re: RFR JDK-8037396: URI getQuery() and getFragment() don't decode properly

Pavel, The code changes and test update look good to me. I think I agree with the approach here, but just to clarify the change in behavior, that will be visible after the changes. $ cat Test.java public class Test { public static void main(String[] args) throws Exception { java.

Re: RFR JDK-8037396: URI getQuery() and getFragment() don't decode properly

s issue before now, which probably indicates use of '[]' in those components is uncommon. Michael On 04/04/14 16:01, Chris Hegarty wrote: Pavel, The code changes and test update look good to me. I think I agree with the approach here, but just to clarify the change in behavior, that will

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

Following JDK-8004963: "URLConnection, downgrade normative reference to ${java.home}/lib/content-types.properties", this bug [1] moves content-types.properties out of the image lib directory and into resources.jar ( to be loaded as a resources file ). This approach is acceptable, since the file

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

Adding build-dev ( for the makefile changes ). -Chris. Original Message Subject: RFR [9] 8039362: Read content-types.properties as a resource Date: Mon, 07 Apr 2014 15:27:43 +0100 From: Chris Hegarty To: OpenJDK Network Dev list Following JDK-8004963: "URLConne

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

ensions=.bmp; + text/html: \ description=HTML Document;\ file_extensions=.htm,.html;\ [3] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46b53f80ab0a > > /Erik > > On 2014-04-07 16:33, Chris Hegarty wrote: >> Adding build-dev ( for the makefile changes ). >>

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

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

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

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

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

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

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, ..."

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

t if you think we should change it then we should probably change URL too. -Chris. Michael On 08/04/14 20:03, Chris Hegarty wrote: java.net.URLConnection.getContent() incorrectly specifies the default location of content handler classes as sun.net.www.content. ( this location is implementation

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

This is a nice addition, and looks very good to me. Just a few small comments: 1) SocketImpl getOption/setOption need javadoc to describe how they can throw IOException. Maybe even the same, of similar javdoc to the socket type equivalent methods? 2) New protected methods in SocketImpl ne

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

ckage, that should not be in the public API. -Chris. On 09/04/14 12:44, Michael McMahon wrote: Chris, Okay, I think it's fine then. The term "default package" is used, but I accept it's not referred to as such, in the JLS. Thanks, Michael On 09/04/14 12:42, Chris Hegarty wrot

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

wrote: On 09/04/2014 14:13, Chris Hegarty wrote: Flip-flop! Thinking again about this, you're right. http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report.html http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report_01.html I could go further with this change, but I just wa

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

On 09/04/2014 22:18, Alan Bateman wrote: On 09/04/2014 18:21, Chris Hegarty wrote: Michael, Alan There is/was an additional reference to the implementation specific package name in ContentHandler. It is now removed. I think this is the last one! Latest specdiff: http://cr.openjdk.java.net

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

Re: [8u-dev] RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

This looks mainly good to me. Just a few small comments (mainly on the use of reflection): 1) jdk/net/Sockets.java You could use a SharedSecret to access the private methods in the public java.net package, but reflection is ok too. 2) If you stick with reflection then if a lookup of any o

Re: Code review request, JDK-8040062 Need to add new methods in BaseSSLSocketImpl

+1 . Thanks for updating this Xuelei. Nice test that caught this. -Chris. On 14/04/14 13:59, Sean Mullan wrote: Looks fine to me. Can you add a relates to link to JDK-8036979 and an appropriate noreg label? --Sean On 04/14/2014 06:04 AM, Xuelei Fan wrote: Hi, Please review the fix for JDK-8

RFR [9] 8040038 : Test java/net/URLPermission/nstest/lookup.sh fails with ClassNotFoundException

It looks like the change for JDK-8027221 missed an @build on the dependent library type, Util. This is just another sighting of the dreaded @library with -conc issue. diff --git a/test/java/net/URLPermission/nstest/lookup.sh b/test/java/net/URLPermission/nstest/lookup.sh --- a/test/java/net/U

Re: RFR [9] 8040038 : Test java/net/URLPermission/nstest/lookup.sh fails with ClassNotFoundException

On 14/04/14 16:28, Alan Bateman wrote: On 14/04/2014 16:30, Chris Hegarty wrote: It looks like the change for JDK-8027221 missed an @build on the dependent library type, Util. This is just another sighting of the dreaded @library with -conc issue. diff --git a/test/java/net/URLPermission

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

Latest changes: http://cr.openjdk.java.net/~chegar/8039470/03/specdiff/java/net/package-summary.html http://cr.openjdk.java.net/~chegar/8039470/03/webrev/ -Chris. On 10 Apr 2014, at 08:49, Chris Hegarty wrote: > > On 10 Apr 2014, at 08:36, Alan Bateman wrote: > >> On 0

Re: RFR [9] 8040837: Avoid provoking NFEs when initializing InetAddrCachePolicy

On 21 Apr 2014, at 20:11, Claes Redestad wrote: > Hi again, > > please review the latest revision, which fixes a small discrepancy where > Security.getProperty was used instead of System.getProperty (implicitly > called by Integer.getInteger in the original code): > > http://cr.openjdk.java.n

Re: RFR JDK-8041563: ProblemList.txt updates

Looks ok to me Michael. I can sponsor this change for you. -Chris. On 23/04/14 10:01, hefeng cui wrote: Hi, Please review the my code changes for JDK-8041563 Here is the webrev link : http://cr.openjdk.java.net/~ewang/michael/JDK-8041563/webr

Re: Proxied https connection reuse by sun.net.www.http.HttpClient can send CONNECT to the destination server

dk.java.net/~arieber/8025710/webrev.00/ thanks Andreas On 24.12.2013 15:01, Chris Hegarty wrote: Andreas, Steven, I updated the bug and assigned it to myself ( to remind me to sponsor the change ). I'll need to look at the changes in a little more detail, but at f

Re: RFR: 8041397: Lint regression in java.net.SocketOption

> On 23 Apr 2014, at 17:07, roger riggs wrote: > > Hi Michael, > > Looks fine. +1 -Chris. > > Roger > > >> On 4/23/2014 11:56 AM, Michael McMahon wrote: >> Could I get the following small change reviewed please? >> >> It fixes a number of recently introduced lint warnings >> >> http://c

[8u20] Request for approval/Review for CR 8041931: test/sun/net/www/http/HttpClient/B8025710.java fails in 8 Update

Hi 8u maintainers, Stupidly I mixed up testing results, and consequently pushed a new test to 8u-dev [1] that has a minor issue, that causes it to fail on all platforms, all of the time. Root cause, the keystore used by the test has moved location in JDK 9, and the test should be updated to ref

Re: RFR: 8041621: java/net/Inet4Address/textToNumericFormat.java fails on Solaris and Mac

This change looks fine to me Michael. -Chris. On 28/04/14 11:59, Michael McMahon wrote: This fixes a recent test failure caused by the change https://bugs.openjdk.java.net/browse/JDK-8040747 which added some new tests of the literal IP address parsing code. The new tests are valid with respect

RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java

com.ibm.icu.lang to package sun.net.idn -// +// 2014-05-01 Chris Hegarty +// - add class level @SuppressWarnings("deprecation") package sun.net.idn; @@ -45,7 +46,7 @@ * @author Syn Wee Quek * @stable ICU 2.1 */ - +@SuppressWarnings("deprecation&

Re: RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java

On 1 May 2014, at 09:16, Alan Bateman wrote: > On 01/05/2014 09:01, Chris Hegarty wrote: >> 8022473 has been logged to request replacements for the deprecated >> UCharacterEnums, but for now the deprecated warnings from >> UCharacterDirection should be suppressed. >>

Re: RFR: 8034170: Digest authentication interop issue

Michael, So this change adds a net/system property to revert to the old behaviour, which makes sense. And the name is in line with the other http.auth.digest.* properties. I agree with this approach. Specifically on the changes, just a few comments: 1) delimCompatFlag can be made final, by rem

Re: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound

Looks good to me Pavel. I can sponsor this change for you. -Chris. On 27 May 2014, at 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > > Thanks > -Pavel

Re: RFR: 8044029 - JNI exception pending checks in java.net

This looks ok to me Mark. Reviewed. -Chris. On 28/05/14 14:49, Mark Sheppard wrote: Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8044029/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8044029 which is a backport of https://bugs.openjd

Re: [8u-dev] RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

Since these APIs are not in 1.8 FCS, is there another way to indicate what release they were added in? -Chris. On 04/06/14 09:51, Michael McMahon wrote: Hi Deven, Thanks for pointing that out. I'll see if we can fix it in time for 8u20. In fact, it should really have the same value in JDK 9 a

RFR [9] 8044590: Broken links in jre.api.net.socketoptions

Looks like a typo in the original @link tag: diff --git a/src/share/classes/jdk/net/Sockets.java b/src/share/classes/jdk/net/Sockets.java --- a/src/share/classes/jdk/net/Sockets.java +++ b/src/share/classes/jdk/net/Sockets.java @@ -51,7 +51,7 @@ * When a security manager is installed, some no

Re: RFR: 8044766 New jdk.net classes have @since 1.9 tags in 8u20

The changes look ok to me Michael. -Chris. On 4 Jun 2014, at 11:58, Michael McMahon wrote: > I'd like to make the same change in 8u-dev > > http://cr.openjdk.java.net/~michaelm/8044766/webrev.1/ > > Thanks, > Michael.

Re: RFR JDK-8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses

This looks good to me Pavel. -Chris. On 6 Jun 2014, at 18:42, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8027308? > > http://cr.openjdk.java.net/~prappo/8027308/webrev.00/ > > The issue in question actually consists of 2 issues. The first one is about >

Re: RFR JDK-8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses

etter. > > -Pavel > > On 9 Jun 2014, at 07:49, Alan Bateman wrote: > >> On 09/06/2014 06:40, Chris Hegarty wrote: >>> This looks good to me Pavel. >>> >>> -Chris. >> It looks okay to me too, I was just wondering if it would be simpler to use >> host.substring + sb.append(']'). >> >> -Alan >> >

Re: RFR JDK-8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses

uilder completely. It doesn't seem to be a >>> performance critical part of the code :) But from the readability >>> perspective this is a lot better. >>> >>> -Pavel >>> >>> On 9 Jun 2014, at 07:49, Alan Bateman wrote: >>> >>>> On 09/06/2014 06:40, Chris Hegarty wrote: >>>>> This looks good to me Pavel. >>>>> >>>>> -Chris. >>>> It looks okay to me too, I was just wondering if it would be simpler to >>>> use host.substring + sb.append(']'). >>>> >>>> -Alan >>>> >> >

Re: RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

On 12/06/14 21:04, Michael McMahon wrote: On 12/06/14 20:35, Alan Bateman wrote: On 12/06/2014 20:15, Michael McMahon wrote: It would be possible to change the error back, but what about supportedOptions() - what should that return? It doesn't seem right that it would include an option that

Re: RFR: 8047187: Test jdk/net/Sockets/Test.java fails to compile after fix JDK-8046588

Looks good to me Michael. -Chris. On 18 Jun 2014, at 14:54, Michael McMahon wrote: > This is a simple test case fix for 8u-dev only. Unfortunately, the test case > for 9 was backported in its entirety and makes calls to APIs not available in > 8. > > http://cr.openjdk.java.net/~michaelm/80471

RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode

This test has been seen to fail occasionally when run with concurrency enabled. I believe the reason to be two fold: 1) The order of the tags may trigger the compilation of the test classes before the library classes, causing the test classes to implicitly compile the library classes in

Re: RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode

On 23/06/14 11:55, Alan Bateman wrote: On 23/06/2014 11:51, Chris Hegarty wrote: This test has been seen to fail occasionally when run with concurrency enabled. I believe the reason to be two fold: I don't know if the order matter here because the @build should compile all of jdk.testli

Re: RFR: JDK-8050922 - add additional diagnostic to java/net/MulticastSocket/TestInterfaces.java

Looks ok to me Mark, and inline with what we have done to other similar tests. -Chris. On 17 Jul 2014, at 12:01, Mark Sheppard wrote: > Hi, > please oblige and review the following diagnostic output addition to > the test java/net/MulticastSocket/TestInterfaces.java > > http://cr.openjdk.jav

Re: RFR: 8031435: Ftp download does not work properly for ftp user without password

Looks good to me Rob. -Chris > On 24 Jul 2014, at 21:54, Rob McKenna wrote: > > Hi folks, > > Very simple fix to allow FtpURLConnection connect without a password in the > url. (i.e. ftp://user@server/ as opposed to the current ftp://user:@server) > > http://cr.openjdk.java.net/~robm/8031435

<    1   2   3   4   5   6   7   8   9   10   >