Re: Code Review Request: 8017779: java/net/Authenticator/B4769350.java fails

/webrev.01/ Thanks, Kurchi On 7/17/2013 2:07 PM, Kurchi Hazra wrote: On 7/17/2013 12:27 AM, Michael McMahon wrote: On 16/07/13 20:11, Kurchi Hazra wrote: Hi, We have observed that test/java/net/Authenticator/B4769350.java fails intermittently. Although not reproducible always, the bug could

Re: Code Review Request: 8020498: Crash when both libnet.so and libmawt.so are loaded

Alright, I'll add it before asking for approval from 7u-dev. - Kurchi On 7/18/2013 11:11 AM, Dmitry Samersoff wrote: Kurchi, As you don't plan to use this function outside of net_util.c it's better to add static keyword as well. -Dmitry On 2013-07-18 21:55, Kurchi Hazra w

Re: Code Review Request: 8020498: Crash when both libnet.so and libmawt.so are loaded

Hi Chris, Thanks for the additional information. How about this fix: http://cr.openjdk.java.net/~khazra/8020498/webrev.01/ - Kurchi On 7/18/2013 2:44 AM, Chris Hegarty wrote: On 18/07/2013 01:19, Kurchi Hazra wrote: Hi, We are seeing a crash when both libmawt.so and libnet.so are loaded

Code Review Request: 8020498: Crash when both libnet.so and libmawt.so are loaded

Hi, We are seeing a crash when both libmawt.so and libnet.so are loaded, and the init() method in src/share/native/java/net/net_util.c is called, but an init() method in libmawt.so gets invoked instead. Although it is difficult to reproduce the problem, declaring the init() in net_util.c ca

Re: Code Review Request: 8017779: java/net/Authenticator/B4769350.java fails

On 7/17/2013 12:27 AM, Michael McMahon wrote: On 16/07/13 20:11, Kurchi Hazra wrote: Hi, We have observed that test/java/net/Authenticator/B4769350.java fails intermittently. Although not reproducible always, the bug could be in the test/sun/net/www/httptest library that this test uses

Code Review Request: 8017779: java/net/Authenticator/B4769350.java fails

Hi, We have observed that test/java/net/Authenticator/B4769350.java fails intermittently. Although not reproducible always, the bug could be in the test/sun/net/www/httptest library that this test uses. I have rewritten the test to use com.sun.net.httpserver instead since we anyway want to

Re: [8] Request for review: 8020318: Fix doclint issues in java.net

Hi Jason, I see just one minor issue: CookieStore.java - the license year should be 2005, 2013? Else looks good. Thanks, Kurchi On 7/10/2013 5:11 PM, Joe Darcy wrote: Hi Jason, Looks good; approved to go back. Thanks, -Joe On 07/10/2013 05:00 PM, Jason Uh wrote: Hi Joe, Please review t

Re: RFR JDK8017079

Looks good. - Kurchi On 6/27/2013 10:09 AM, Chris Hegarty wrote: Looks good to me John. -Chris. On 27/06/2013 18:02, John Zavgren wrote: Greetings: Please consider the following socket constructor changes: http://cr.openjdk.java.net/~jzavgren/8017079/webrev.01/

Re: RFR JDK8015799

/net-dev/2013-June/006607.html On 06/26/2013 08:22 PM, Kurchi Hazra wrote: On 6/26/2013 12:17 PM, Kurchi Hazra wrote: Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; I meant return null. For other cookie-headers too, is there

Re: RFR JDK8015799

On 6/26/2013 12:17 PM, Kurchi Hazra wrote: Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; I meant return null. For other cookie-headers too, is there any reason for us not returning null if the length of value is 0? Also

Re: RFR JDK8015799

Hi John, Why not change lines 2810-2811 to: if (value == null || value.length() == 0) return value; Also, lots of formatting issue in the test, especially in TestCookieHandler, try-catch block indentation is off in line 54. Its also best to stop the server in a finally clause at

Re: 6563286: HttpURLConnection.followRedirect(..) follows malformed url.

Hi Andreas, Your changes look good to me. 5069130 had been closed as not a defect - since we throw an unchecked exception, and was decided to be the right course of action. Now, I don't have a problem with changing the code to throw a checked exception in this case - but we have to wait fo

Re: RFR 8017271: Crash may occur in java.net.DualStackPlainSocketImpl::initIDs due to unchecked values returned from JNI functions

Looks good to me too. On 6/21/2013 7:03 AM, Alan Bateman wrote: On 21/06/2013 14:50, Chris Hegarty wrote: There is a remote possibility that FindClass can return NULL, for a class we expect to exist, OOM, etc. Best practice is to check the return value before attempting to use it. CHECK_NULL

Re: 7025238 : HttpURLConnection does not handle URLs with an empty path component

mpty. True, ParserUtil.toUri() uses the path and query elements separate. Here in HttpClient.java i guess it saves at least one null check ;-) cheers Andreas On 19.06.13 20:02, Kurchi Hazra wrote: Hi Andreas, I looked at your changes, and they look good to me. Although we are not changing the path

Re: 7025238 : HttpURLConnection does not handle URLs with an empty path component

Hi Andreas, I looked at your changes, and they look good to me. Although we are not changing the path of the URL itself (it is not modifiable too), but from what I see the only other relevant place where URL.path is logically used in http client is in ParseUtil.toURI(), which basically does

Re: Code Review Request: 8015421: NegativeArraySizeException occurs in ChunkedOutputStream() with Integer.MAX_VALUE

Apologies, I had used the wrong subject line - correcting it here for records. On 6/12/2013 11:41 AM, Kurchi Hazra wrote: Right, what I have now should not be really problematic, it will throw an OutOfMemoryError and I pass the test in that case. But I am ok with skipping it too. I'll

Code Review Request: 7169142: CookieHandler does not work with localhost

Hi, The problem that this bug points out is that when a cookie is from a localhost and no domain is set, our implementation sets the default domain of the cookie to its uri.getHost() [1], (which is localhost here), and since the domain now does not contain .local, the cookie gets rejected

Re: Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

ing tests in the samevm concurrently. -Chris -Chris On 12 Jun 2013, at 18:48, Kurchi Hazra wrote: Hi, In HttpUrlConnection, if the chunk length is set to Integer.MAX_VALUE, our code was trying to initialize a buffer of size greater than that, which was resulting in an integer over

Re: Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

Thanks Matthew! That is what I have currently. - Kurchi On 6/12/2013 11:07 AM, Matthew Hall wrote: Put the relevant part of the test in try-catch. If you get OOME skip / ignore. If you get NASE, then you have a regression.

Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

Hi, In HttpUrlConnection, if the chunk length is set to Integer.MAX_VALUE, our code was trying to initialize a buffer of size greater than that, which was resulting in an integer overflow, and consequently a NegativeArraySizeException. This fix ensures that while initializing the internal bu

Re: Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

How does this look: http://cr.openjdk.java.net/~khazra/7051862/webrev.01/ - Kurchi On 6/6/2013 11:15 AM, Kurchi Hazra wrote: On 6/6/2013 2:07 AM, Chris Hegarty wrote: On 06/06/2013 01:06 AM, Kurchi Hazra wrote: Hi, Please review this change to fix 7051862. For ACCEPT_ORIGINAL_SERVER

Re: Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

On 6/6/2013 2:07 AM, Chris Hegarty wrote: On 06/06/2013 01:06 AM, Kurchi Hazra wrote: Hi, Please review this change to fix 7051862. For ACCEPT_ORIGINAL_SERVER, shouldAccept() throws a NullPointerException for null arguments. Out of the many options to fix this, I think the best way is to

Code Review Request: 7051862: CookiePolicy spec conflicts with CookiePolicy.ACCEPT_ORIGINAL_SERVER

Hi, Please review this change to fix 7051862. For ACCEPT_ORIGINAL_SERVER, shouldAccept() throws a NullPointerException for null arguments. Out of the many options to fix this, I think the best way is to return false if either of the arguments is null - based on the fact that HttpCookie.domain

Re: RFR JDK7188517

RFR JDK7188517 John, I think you can simply reinstate http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java -Chris. On 05/08/2013 09:02 PM, Kurchi Hazra wrote: I would have thrown an exception if the IllegalArgumentException is not obtai

Code Review Request: 7150552: network test hangs [macosx]

Hi, Two regression tests in jdk/test were hanging on Mac OS X intermittently. Although it is difficult to reproduce the problem, I suspect it is the use of the buggy httpserver test library (jdk/test/sun/net/www/httptest) - we anyway want to move away from using it. I have re-written parts of

Re: Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions

On 5/13/2013 3:19 AM, Chris Hegarty wrote: On 11/05/2013 00:35, Kurchi Hazra wrote: This is a simple improvement in the javadocs of the Socket and ServerSocket classes, to cross-reference the SocketOptions class where appropriate. It looks like a lot of changes in the webrev, only because I

Code Review Request: 6328537: Improve javadocs for Socket class by adding references to SocketOptions

Hi, This is a simple improvement in the javadocs of the Socket and ServerSocket classes, to cross-reference the SocketOptions class where appropriate. It looks like a lot of changes in the webrev, only because I have re-justified the text in some cases. Bug: http://bugs.sun.com/view_bug.d

Re: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive

. http://cr.openjdk.java.net/~khazra/8014254/webrev.01/ - Kurchi On 5/9/13 1:45 AM, Chris Hegarty wrote: On 05/09/2013 01:56 AM, Kurchi Hazra wrote: On 5/8/2013 4:35 PM, Matthew Hall wrote: On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: com.sun.net.httpServer uses a selector to get

Re: RFR JDK7188517

John, I think you can simply reinstate http://hg.openjdk.java.net/jdk8/jdk8/jdk/diff/7bd32bfc0539/test/java/net/CookieHandler/TestHttpCookie.java -Chris. On 05/08/2013 09:02 PM, Kurchi Hazra wrote: I would have thrown an exception if the IllegalArgumentException is not obtained, otherwise the

Re: Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive

On 5/8/2013 4:35 PM, Matthew Hall wrote: On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote: com.sun.net.httpServer uses a selector to get notified about interesting events (such as arrival of a new connection, or data available to read on an existing connection when using keep-alive

Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive

Hi, com.sun.net.httpServer uses a selector to get notified about interesting events (such as arrival of a new connection, or data available to read on an existing connection when using keep-alive), but imposes a timeout of 1000 ms on the select() operation. Although this is not a problem whe

Re: RFR JDK7188517

10:28 PM, Kurchi Hazra wrote: This looks okay to me. Source changes look fine to me too. Probably best to add a test for '$' In fact, Michael actually removed such a test [1] during another change. We should get positive agreement from Michael before pushing this. Yes, that was

Re: RFR JDK7188517

This looks okay to me. - Kurchi On 5/2/2013 10:09 AM, John Zavgren wrote: All: My original email was mangled by my email program (stbeehive/zimbra) ... so I'm sending a second correctly formatted copy. I'm sorry for the inconvenience. John --- Please consider the following cha

Re: Code Review Request: 8013140: Heap corruption with NetworkInterface.getByInetAddress() and long i/f name

Thank you, committed now. - Kurchi On 5/2/2013 3:50 AM, Alan Bateman wrote: On 02/05/2013 01:03, Kurchi Subhra Hazra wrote: Hi, NetworkInterface.getByInetAddress() was crashing on solaris when the system had a network interface name longer than 15 characters, due to two instances in the

Re: API change for 8010464: Evolve java networking same origin policy

Hi Michael, From the documentation, it is not clear to me how to represent both request-headers and method list together in an actions string for two or more methods. (Say I have two methods GET and POST and I want to specify a request-headers list for each, how do I do it?) Maybe another

Re: RFR-JDK8012108

Thanks John, I think the leak is taken care of now, I can sponsor the change for you once you have a thumbs up from everyone. - Kurchi On 4/18/2013 1:56 PM, John Zavgren wrote: Greetings: I fixed a case in the windows native code where calloc() was being used without checking it's returned v

Re: RFR-8012108

Hi John, Does this actually fix the leak? When curr is null, you set start to curr, and hence start to null. So nothing is every freed in freeAllocatedMemory is what I see. Let me know if I am missing something. - Kurchi On 4/17/2013 8:02 AM, John Zavgren wrote: Greetings: Please review th

Re: DefaultProxySelector socks override

sProxyHost. On 4/2/2013 5:13 PM, Kurchi Hazra wrote: Hi Christos/Chris, Here is a webrev for this change: http://cr.openjdk.java.net/~khazra/5001942/webrev.00/ Thanks, - Kurchi On 3/27/2013 10:49 AM, chris...@zoulas.com wrote: On Mar 27, 5:30pm, chris.hega...@oracle.com (Chris Hega

Re: DefaultProxySelector socks override

Hi Christos/Chris, Here is a webrev for this change: http://cr.openjdk.java.net/~khazra/5001942/webrev.00/ Thanks, - Kurchi On 3/27/2013 10:49 AM, chris...@zoulas.com wrote: On Mar 27, 5:30pm, chris.hega...@oracle.com (Chris Hegarty) wrote: -- Subject: Re: DefaultProxySelector socks ov

Re: RFR 8010282: sun.net.www.protocol.jar.JarFileFactory.close(JarFile) should be thread-safe

The if statements in the platform specific close methods do not have the spaces as we usually prefer to have them (I realize from before your changes), but otherwise this looks good to me. - Kurchi On 3/19/2013 10:43 AM, Chris Hegarty wrote: JarFileFactory has two Maps that it uses to implemen

Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed

I looked at the source code changes, and it looks good. Thanks, - Kurchi On 3/13/2013 7:42 AM, Chris Hegarty wrote: The source code changes look fine to me. I'm not sure why you enabled a security manager in the test. I don't think that it needs one. You can remove the explicit setting of th

Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed

Thanks Rob. Also, I am now looking at the previous changeset[1] where the regression was introduced, once available() figures out that a cached connection is no longer active, it should probably be removed from the cache. (setting ret to null doesn't remove it from the cache). If there were o

Re: RFR 8008223: java/net/BindException/Test.java fails rarely

I tried out your fix and your solution looks good to me. Thanks, Kurchi On 2/14/2013 6:43 AM, Chris Hegarty wrote: Webrev: http://cr.openjdk.java.net/~chegar/8008223/webrev.00/webrev/ This test has been around a long time, and rarely fails, but has had several bugs closed as 'not reproducib

Re: Code Review Request: 7017962: Obsolete link is used in URL class level spec

09:27 , Kurchi Hazra wrote: Apologies, but I have a new suggestion. It is safer to redirect to an archived version of the document that we want to link to. http://cr.openjdk.java.net/~khazra/7017962/webrev.01/src/share/classes/java/net/URL.java.sdiff.html Thanks to Mike for pointing this out. - Kurch

Re: Code Review Request: 7017962: Obsolete link is used in URL class level spec

:52, Chris Hegarty wrote: Thanks Kurchi, I'm ok with the changes you have. -Chris. On 23/01/2013 00:20, Kurchi Hazra wrote: The current javadoc for URL.java points to a non-existent link [1] to explain different types of URLs used by different protocols. The same document can currently be

Code Review Request: 7017962: Obsolete link is used in URL class level spec

The current javadoc for URL.java points to a non-existent link [1] to explain different types of URLs used by different protocols. The same document can currently be found at [2]. Bug: http://bugs.sun.com/view_bug.do?bug_id=7017962 Webrev: http://cr.openjdk.java.net/~khazra/7017962/webrev.00/

Re: Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

Kurchi Thanks Sent from my phone On Jan 8, 2013 8:20 PM, "Kurchi Hazra" mailto:kurchi.subhra.ha...@oracle.com>> wrote: Hi, According to RFC 3986[1], hexadecimal digits encoded by a '%' should

Code Review Request: 7171415: java.net.URI.equals/hashCode not consistent for some URIs

Hi, According to RFC 3986[1], hexadecimal digits encoded by a '%' should be case-insensitive, for example,%A2 and %a2 should be considered equal. Although, URI.equals() does take this into consideration, the implementation of URI.hashCode() does not and returns different hashcodes for two U

Fwd: InetAddress.getAllByName()/getByName() fails to resolve IPv6 via ssh

Forwarding to net-dev Hi Charis, I tried to recreate this, I ran your code remotely (from both Linux and Windows onto a Linux machine) but could not get an UnkownHostException if the code works without an exception when run locally on a machine. Can you be more specific about the operatin

Re: RFR 8004675: Inet6Address.getHostAddress should use string scope identifier where available

Looks good to me. Not related to this bug, but do we need scope_id_set then? From what I infer, scope_id_set is being set in native code, only when scope_id is not 0, and so a check with scope_id == 0 can serve the purpose of scope_id_set too. Thanks, Kurchi On 10.12.2012 08:01, Chris Hegart

Re: RFR8003991 (take two)

Aren't we effectively calling fclose(NULL) here now? - Kurchi On 26.11.2012 15:19, John Zavgren wrote: Greetings: I'm posting the webrev image of a change that I made that eliminates a potential file descriptor leak. (The previous RFR referenced a webrev image with the right file name but th

Re: getportbyname in Java?

I don't think so... Thanks, - Kurchi On 13.11.2012 16:40, Weijun Wang wrote: Is there a Java API I can translate "http" to 80? Thanks Max -- -Kurchi

Re: RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.

Sounds good, thanks a lot. - Kurchi On 24.10.2012 10:47, John Zavgren wrote: That's right Kurchi. If realloc were to fail, in the original code, then the pointer: loRoutes would be set to the value zero, but the memory that this variable previously pointed to would still be allocated. So, ba

Re: RFR 8000203: file descriptor leak, src/solaris/native/java/net/net_util_md.c ... AND a potential realloc()-related memory leak.

Just for the sake of understanding the fix better, loRoutesTemp will point to 0 if the realloc() request fails, and we still need a reference to the older allocated memory (loRoutes in this case) in order to free it. Hence the need for a temporary variable here? - Kurchi On 24.10.2012 06:27,

Re: Change to: ./src/solaris/native/java/net/PlainDatagramSocketImpl.c

Hi John, This change looks good to me. Thanks, - Kurchi On 18.10.2012 14:18, Dmitry Samersoff wrote: John, Looks good for me. -Dmitry On 2012-10-19 00:59, John Zavgren wrote: Greetings: I'm proposing the following change: http://cr.openjdk.java.net/~khazra/john/8000206/webrev.00/ becau

Re:

Forwarding this to the networking mailing list. Do you know of any way to reproduce the problem, like a small test case that we(I) could try? Thanks, Kurchi On 8/29/2012 4:45 PM, Earle Nietzel wrote: Seeing the following Warning multiple times every few seconds. Aug 29, 2012 7:09:26 PM sun.

Re: CR: 7183292: HttpURLConnection.getHeaderFields() throws IllegalArgumentException: Illegal cookie name

- Looks fine to me. - Kurchi On 7/18/2012 10:38 AM, Michael McMahon wrote: Thanks Kurchi. I have made one small change to another test, which was specifically testing the $name assertion. So, that test had to be removed. The new webrev is at : http://cr.openjdk.java.net/~michaelm/7183292/

Re: Code Review Request: 6953455 CookieStore.add() cannot handle null URI parameter, contrary to the API specification

Jul 2012, at 15:19, Neil Richards wrote: On Fri, 2011-09-30 at 10:08 -0700, Kurchi Hazra wrote: Hi, The CookieStore.add() method throws a Null Pointer Exception when null is passed as the uri parameter, although this is allowed according to the method spec. The exception is thrown

Code Review Request: 7171591: getDefaultScopeID() in src/solaris/native/java/net/net_util_md.c should return a value

Hi, This is an oversight in the fix for 7144274, where I introduced a method getDefaultScopeID() to retrieve the default scope id in Mac OS X. The macro used for checking whether the variable passed is null should return an integer value, since the method getDefaultScopeID() is declared to r

Re: Code Review Request : 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup()

file: ni_defaultIndexID = (*env)->GetStaticFieldID(env, c, "defaultIndex", "I"); And indented 5 (one to many) spaces after the closing if bracket. No need to regenerate the webrev, I'm happy for you to push. -Chris.

Code Review Request : 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup()

Hi, Before joining multicast groups with IPv6 addresses on Mac OS, the network interface to be used should also be set correctly. This change enables using a default network interface on Mac OS X if no interface has been specified. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=714

Code Review Request: 7162385: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing again

Hi, This test was recently fixed via: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31c15e2f51ba However, it was failing again with a FileNotFoundException since it could not find foo1.jar (wrt the test source). This webrev fixes the test. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug

Re: Code Review Request: 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN

Bateman wrote: On 17/04/2012 19:47, Kurchi Hazra wrote: Hi, In Windows Vista and later, InterfaceAddress.getBroadcast() returns 0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to handle IF_TYPE_IEEE80211 in the

Code Review Request: 7158636: InterfaceAddress.getBroadcast() returns invalid broadcast address on WLAN

Hi, In Windows Vista and later, InterfaceAddress.getBroadcast() returns 0.0.0.0 , since these platforms return IF_TYPE_IEEE80211 instead of MIB_IF_TYPE_ETHERNET for wireless interface type now. The fix is to handle IF_TYPE_IEEE80211 in the relevant switch statement. While doing this, I also upd

Re: Code Review Request: 7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows

expects a CRLF, and that is how this is working. It is a small change, I will anyway correct it. - Kurchi On 4/17/12 3:24 AM, Chris Hegarty wrote: On 16/04/12 22:18, Kurchi Hazra wrote: Hi, Thanks for the reviews. Here is an updated webrev: http://cr.openjdk.java.net/~khazra/7152856/webrev

Re: Code Review Request: 7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows

Hi, Thanks for the reviews. Here is an updated webrev: http://cr.openjdk.java.net/~khazra/7152856/webrev.01 Thanks, Kurchi On 4/15/2012 12:35 AM, Chris Hegarty wrote: On 14/04/12 16:53, Alan Bateman wrote: On 13/04/2012 17:59, Kurchi Hazra wrote: Hi, This test was failing on Windows

Code Review Request: 7152856: TEST_BUG: sun/net/www/protocol/jar/B4957695.java failing on Windows

Hi, This test was failing on Windows since it was using the HttpServer in test/sun/net/www/httptest. The HttpServer implementation there is buggy and does not close the connection properly, resulting in the test hanging. We therefore write our own server, which sends back 10 bytes less than w

Re: Code Review Request: 7045655: An empty InMemoryCookieStore should not return true for removeAll

4/03/12 22:36, Kurchi Hazra wrote: The CookieStore.removeAll() is supposed to return true according to its spec, only if the CookieStore changes as a result of the call. InMemoryCookieStore:removeAll() was returning true by default, even if the CookieStore object was already empty, and no changes

Code Review Request: 7045655: An empty InMemoryCookieStore should not return true for removeAll

The CookieStore.removeAll() is supposed to return true according to its spec, only if the CookieStore changes as a result of the call. InMemoryCookieStore:removeAll() was returning true by default, even if the CookieStore object was already empty, and no changes were being done by the call. Thi

Code Review Request: 7144268: [macosx] ProblemList.txt updates to exclude networking tests failing on Mac OS X

Hi, There are a few networking tests failing on Mac OS X due to the following issues: (a) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7122846 (b) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7145658 (Not available yet) (c) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=714396

Re: Code Review Request: 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup()

'. It is just a general utility method to get the value of the defaultIndex field of NetworkInterace. Yes, the value will be 0 on all platforms other than Mac, but equally getDefaultScopeID will not be called on any platform, other than Mac. -Chris. On 02/14/12 07:46 AM, Alan Bateman wrote

Code Review Request: 7144274: [macosx] Default IPv6 multicast interface is not being set when calling MulticastSocket.joinGroup()

Hi, Before joining multicast groups with IPv6 addresses on Mac OS, the network interface to be used should also be set correctly. This change enables using a default network interface on Mac OS X if no interface has been specified. Bug:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144274

Re: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X

I updated the comment: http://cr.openjdk.java.net/~khazra/7127771/webrev.02/ - Kurchi On 1/16/2012 2:43 AM, Michael McMahon wrote: Yes, looks fine to me too. I would just update the comment above this code to add Mac OS to the Solaris case. Thanks Michael On 13/01/12 21:02, Kurchi Hazra

Re: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X

How does this look: http://cr.openjdk.java.net/~khazra/7127771/webrev.01/ - Kurchi On 1/13/2012 12:14 PM, Alan Bateman wrote: Bug : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127771 Webrev : http://cr.openjdk.java.net/~khazra/7127771/webrev.00/ What you have is fine although you c

Re: Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X

Resending this request - Kurchi On 1/11/2012 11:15 AM, Kurchi Hazra wrote: Hi, For IPv6 on solaris or linux, setting the traffic class option is handled in the java layer. The native calls to set socket option simply returns a success and get socket option returns a dummy -1 value. test

Code Review Request: 7127771: (macosx)test/java/net/Socket/TrafficClass.java fails on Mac OS X

Hi, For IPv6 on solaris or linux, setting the traffic class option is handled in the java layer. The native calls to set socket option simply returns a success and get socket option returns a dummy -1 value. test/java/net/Socket/TrafficClass.java was failing on Mac OS X when using the IPv6 st

Re: Review request: 7120875 fix macos ipv6 issue and update multiple test scripts

The changes in the following files are not required I guess - perhaps they are my bad test/java/net/DatagramSocket/B6411513.java ||test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java - Kurchi* * On 12/16/2011 2:36 AM, Michael McMahon wrote: Updated webrev after

Re: Review request: 7120875 fix macos ipv6 issue and update multiple test scripts

On 12/14/2011 12:15 PM, Alan Bateman wrote: On 14/12/2011 20:05, Kurchi Hazra wrote: On 12/14/2011 11:54 AM, Alan Bateman wrote: : In test/sun/net/www/protocol/jar/jarbug/run.sh then maybe it would make sense to combine SunOS, Linux and Darin into the one case. More generally then I

Re: Review request: 7120875 fix macos ipv6 issue and update multiple test scripts

On 12/14/2011 11:54 AM, Alan Bateman wrote: On 14/12/2011 19:39, Michael McMahon wrote: Hi, This webrev fixes a bunch of test script issues in networking and core-libs. In most if not all cases, the change relates to recognising the OS that the test is running on. It also fixes an IPv6 is

Code Review Request: 7107020: java.net.PlainSocketImpl.socketSetOption() calls itself

Hi, As specified in the CR description, this is a bug in src/windows/java/net/PlainSocketImpl.java and impl.socketSetOption() should be called instead of socketSetOption(). This bug did not create a problem yet since setOption() is usually called for setting socket options. Submitting hg d

Code Review Request: 6953455 CookieStore.add() cannot handle null URI parameter, contrary to the API specification

Hi, The CookieStore.add() method throws a Null Pointer Exception when null is passed as the uri parameter, although this is allowed according to the method spec. The exception is thrown because uri.getHost() is called on a null uri in an effort to add it to the uriIndex, one of th

Code Review Request: 7084030 DatagramSocket.getLocalAddress inconsistent on XP/2003 when IPv6 enabled and socket is connected

Hi, The DatagramSocket.getLocalAddress() method was returning a wildcard address when a DatagramSocket is created and then connected to a remote address, on windows XP/Server 2003 machines with IPv6 enabled. However, for adhering to the spec as well as being consistent across all platform

Re: Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

chi we should probably run with this. -Chris. On 14/09/2011 16:46, Kurchi Hazra wrote: I remember having made this change as follows: -bash-3.00$ hg diff src/share/classes/java/net/Socket.java diff --git a/src/share/classes/java/net/Socket.java b/src/share/classes/java/net/Socket.java --- a/s

Re: Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

3. java/net/DatagramSocket.java and java/net/MulticastSocket.java have some real code changes around bind(). Maybe they should go to another fix? I think there is some merging problem in my workspace. I will probably start with an updated copy of these files and insert my changes in them. S

Re: Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

ote: On 09/14/2011 12:14 PM, Kurchi Hazra wrote: Updated webrev : http://cr.openjdk.java.net/~weijun/7090158/webrev.00/. This should build correctly. Yes, it does! Some comments: 1. make/java/Makefile has no real change 2. make/javax/others/Makefile has only a new commented line

Re: Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

. Most in src/share/classes/javax/xml/crypto/dsig and I remember Sean said it's not easy to remove all warnings there because the codes are shared between JDK and some Apache projects. -Max On 09/14/2011 03:13 AM, Alan Bateman wrote: Kurchi Hazra wrote: Something went wrong in the pasting

Re: Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

Something went wrong in the pasting. Can you check if this works fine: http://cr.openjdk.java.net/~chegar/7090158/webrev/ On 9/13/2011 12:07 PM, Alan Bateman wrote: Kurchi Hazra wrote: Hi, This is an attempt to remove all build warnings that are related to networking in jdk. This work

Code Review Request: 7090158 Networking Libraries don't build with javac -Werror

Hi, This is an attempt to remove all build warnings that are related to networking in jdk. This work contains (a) Small changes in java files to remove already existing warnings (b) Small changes in Makefiles to prevent re-introduction of such warnings. Webrev: http://cr.openjdk.java.net/~c

Code Review Request: 7084032: test/java/net/Inet6Address/B6558853.java fails on Windows XP/2003 if IPv6 enabled

Hi, test/java/net/Inet6Address/B6558853.java tests if the address obtained from getHostAddress() on connections using IPv6 link-local addresses contains the zone id. For Inet6Address.getHostAddress() to return the zone id, Inet6Address.scope_id_set needs to be set to true in addition to set

Code Review Request: 6978200 ServerSocket.toString include "port=0" in the returned String

Hi, The ServerSocket.toString method returns a string that, besides the ServerSocket's local port information, also contains "port=0". For example: "ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=7005]". The fix aims at modifying the string returned by the toString method by removing i

Re: hg: jdk8/tl/jdk: 7035556: DatagramSocket.java:183: warning: unreachable catch clause

Thanks a lot and I look forward to making more contributions too! Thanks, Kurchi On 7/25/2011 2:52 PM, Chris Hegarty wrote: Congratulation Kurchi on your first contribution to OpenJDK. Hope to see more in the future. -Chris. On 07/25/11 10:42 PM, chris.hega...@oracle.com wrote: Changeset: 0

Re: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause

Hi, I changed the implementation according to Brad's comments. I am reposting the output of hg diff src/share/classes/java/net/DatagramSocket.java since I don't have an openjdk account: bash-3.00$ hg diff src/share/classes/java/net/DatagramSocket.java diff --git a/src/share/classes/java/n

Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause

Hi, Due to a recent update in javac to issue a warning on detecting unreachable code, the following warning started showing up in the jdk networking code: ../../../src/share/classes/java/net/DatagramSocket.java:183: warning: unreachable catch clause. This fix aims at removing this warning by