Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX

Looks fine to me Rob, thanks. -Chris. On 09/20/2013 03:58 PM, Rob McKenna wrote: After a brief discussion with Chris, we decided to revert the position of the call to lookupIfLocalAddrs so as to give the local host primacy over DNS. Latest (and hopefully last) webrev here: http://cr.openjdk.j

Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl

The changes look fine to me. -Chris. On 10/01/2013 12:53 PM, Seán Coffey wrote: Taken feedback on board. New webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952.2/webrev/ I've managed to get confirmation from original submitter that this works ok for them. regards, Sean. On 20/09/201

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On 02/10/2013 04:44, Alan Bateman wrote: On 01/10/2013 12:46, Brian Burkhalter wrote: : I updated the webrev http://cr.openjdk.java.net/~bpb/8010371/ with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. Brian

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On 02/10/2013 15:58, Michael McMahon wrote: On 02/10/13 15:40, Chris Hegarty wrote: On 02/10/2013 04:44, Alan Bateman wrote: On 01/10/2013 12:46, Brian Burkhalter wrote: : I updated the webrev http://cr.openjdk.java.net/~bpb/8010371/ with changes in the test of the return value of

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

On 10/02/2013 08:40 PM, Brian Burkhalter wrote: So, how about this approach: 1) If the error is EAI_AGAIN / EIA_SYSTEM+EAGAIN / WSATRY_AGAIN then do one immediate native retry. 2) If the retry fails with the same error, then throw a UHE with a specific message or cause. Sounds good to m

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

what that should be ). The use of Thread.yield(), if acceptable, would of course most likely make sense to push the retry logic back up into the Java level. -Chris. -Dmitry On 2013-10-02 23:53, Chris Hegarty wrote: On 10/02/2013 08:40 PM, Brian Burkhalter wrote: So, how about this

Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown

h more work and probably out of scope of this CR. -Dmitry On 2013-10-03 13:11, Chris Hegarty wrote: On 10/02/2013 11:18 PM, Dmitry Samersoff wrote: Chris, I'm not sure immediate native retry make sence here because tipically EAGAIN of getaddrinfo caused by network failure, like unreachable

hg: jdk8/tl/jdk: 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash

Changeset: 7d2112abbb1d Author:coffeys Date: 2013-10-04 16:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d2112abbb1d 8016271: wsimport -clientjar does not create portable jars on Windows due to hardcoded backslash Reviewed-by: mkos, chegar + test/javax/xml/ws/clientjar

hg: jdk8/tl/jaxws: 2 new changesets

Changeset: b0610cd08440 Author:mkos Date: 2013-10-04 16:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b0610cd08440 8025054: Update JAX-WS RI integration to 2.2.9-b130926.1035 Reviewed-by: chegar ! src/share/jaxws_classes/com/oracle/webservices/internal/api/databinding

Re: RFR: 8025734: Use literal IP address where possible in SocketPermission generated by HttpURLPermission

The changes look good to me. -Chris. On 08/10/2013 12:43, Michael McMahon wrote: Hi, This change updates HttpURLPermission to grant a SocketPermission with a literal IP address rather than the String hostname when the IP address is available (this gets looked up anyway. So, we're not adding an

Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed

Do you have a sense of how long this test runs for, on an average machine, with the extra iterations? -Chris. On 09/10/2013 09:24, Ivan Gerasimov wrote: Hello all! The MemLeakTest had been added with the fix for 8022584. Since that, the test was reported to fail intermittently, even though th

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

Thank you for doing this Michael. The changes look good to me, but someone from the build group should cast an eye on the makefile changes. -Chris. On 10/10/2013 11:10 AM, Michael McMahon wrote: Can I get the following change for jdk 8 reviewed please? It's a simple build change to enable c

Re: Fix for JDK-8023555

Hi Tristan, Since the test requires a non-localhost machine name, i.e. a real name, then returning silently is probably the right thing to do. I can sponsor this change for you. -Chris > On 12 Oct 2013, at 13:33, Tristan Yan wrote: > > Please review fix for JDK-8023555 > http://cr.openjdk.ja

Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed

ssed during one iteration. Not 3.5, but of course 14 times. Silly arithmetic mistake. However the rest remains true. So on systems with many network interfaces the total time should even be less than before. Nevertheless I doubled the timeout. Sincerely yours, Ivan On 09.10.2013 19:57, Chris Heg

hg: jdk8/tl/jdk: 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost

Changeset: 077237e4613f Author:tyan Date: 2013-10-14 11:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/077237e4613f 8023555: test/java/net/Socks/SocksProxyVersion.java fails when machine name is localhost Reviewed-by: chegar, alanb ! test/java/net/Socks/SocksProxyVersion

Re: RFR [8023390] Test java/net/NetworkInterface/MemLeakTest.java failed

On 10/15/2013 11:19 AM, Ivan Gerasimov wrote: On 14.10.2013 14:28, Chris Hegarty wrote: I'm really not sure that the effort this test is going to is really necessary here ( to verify such a minor leak ). I'd be happy to see the test simply removed. Other opinions? I agree. I o

Re: RFR: JDK-8026245, , InetAddress.getLocalHost crash if IPv6 disabled (macosx)

Thank you Rob, this looks good to me. -Chris. On 10/15/2013 04:32 PM, Rob McKenna wrote: Updated webrev at: http://cr.openjdk.java.net/~robm/8026245/webrev.02/ -Rob On 15/10/13 15:31, Rob McKenna wrote: Caught me. I've just updated the tests in place actually. Another jprt job is in pr

hg: jdk8/tl: 3 new changesets

Changeset: af87dabb4263 Author:msheppar Date: 2013-06-14 15:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/af87dabb4263 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! common/makefiles/RMICompilation.gmk

hg: jdk8/tl/jaxp: 14 new changesets

Changeset: ecb66dc473c1 Author:joehw Date: 2013-07-16 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ecb66dc473c1 8012425: Transform TransformerFactory Reviewed-by: alanb, dfuchs, mullan ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java ! src/com

hg: jdk8/tl/jaxws: 11 new changesets

Changeset: 43240b8b995b Author:mkos Date: 2013-08-01 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/43240b8b995b 8017505: Better Client Service Reviewed-by: mullan, ahgross, mgrebac ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/AbstractInstanceResolve

hg: jdk8/tl/corba: 15 new changesets

Changeset: 81d694b1ab2f Author:msheppar Date: 2013-06-14 16:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/81d694b1ab2f 8011157: Improve CORBA portablility Summary: fix also reviewed by Alexander Fomin Reviewed-by: alanb, coffeys, skoivu ! src/share/classes/com/sun/corb

hg: jdk8/tl/hotspot: 13 new changesets

Changeset: 5c599c419c1d Author:hseigel Date: 2013-07-11 12:59 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c599c419c1d 8016256: Make finalization final Summary: Add private methods to final methods check Reviewed-by: coleenp, acorn, ahgross Contributed-by: harold.sei..

hg: jdk8/tl/jdk: 61 new changesets

Changeset: b3baca585b7f Author:jbachorik Date: 2013-04-23 09:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3baca585b7f 8011081: Improve jhat Summary: Properly escape HTML output Reviewed-by: alanb, mschoene, sundar ! src/share/classes/com/sun/tools/hat/internal/server/A

hg: jdk8/tl/langtools: 14 new changesets

Changeset: 84df20dc604a Author:bpatel Date: 2013-07-24 15:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/84df20dc604a 8016675: Make Javadoc pages more robust Reviewed-by: jlaskey, ksrini ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java +

Re: RFR: 8005068 - HttpCookie does not correctly handle negative maxAge values

Hi Rob, The changes look fine. ( Trivially the copyright year on the test should be 2013 ). Coming so late in the JDK8 development cycle, only P1-3 bugs are being accepted [1]. I see this is a P4. Should it be deferred to the next available minor update, or do you think it warrants being fix

Re: RFR: 8005068 - HttpCookie does not correctly handle negative maxAge values

Chris. -Rob On 21/10/13 16:21, Chris Hegarty wrote: Hi Rob, The changes look fine. ( Trivially the copyright year on the test should be 2013 ). Coming so late in the JDK8 development cycle, only P1-3 bugs are being accepted [1]. I see this is a P4. Should it be deferred to the next available minor u

Re: Fix for https://bugs.openjdk.java.net/browse/JDK-8022211

Hi Tristan, I agree with you, option 2 is probably better. Have you verified Kurchi's changes, tested, reviewed, etc? Have you modified Kurchi's changes from her original review request? I can sponsor this change. Thanks, -Chris. On 22/10/2013 07:22, Tristan Yan wrote: Hi Everyone I have a

Re: 答复: Fix for https://bugs.openjdk.java.net/browse/JDK-8017779

s run, it all passed. Thank you very much Tristan -邮件原件- 发件人: Chris Hegarty 发送时间: Tuesday, October 22, 2013 5:47 PM 收件人: Tristan Yan 抄送: net-dev@openjdk.java.net 主题: Re: Fix for https://bugs.openjdk.java.net/browse/JDK-8017779 Hi Tristan, I agree with you, option 2 is probably better

hg: jdk8/tl/jdk: 8017779: java/net/Authenticator/B4769350.java fails

Changeset: 7cafbb397683 Author:chegar Date: 2013-10-22 14:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cafbb397683 8017779: java/net/Authenticator/B4769350.java fails Reviewed-by: chegar Contributed-by: Tristan Yan , Kurchi Subhra Hazra ! test/java/net/Authenticator/

hg: jdk8/tl/jdk: 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build

Changeset: 6a1989dc302d Author:igerasim Date: 2013-10-15 18:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1989dc302d 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build Summary: Removing the test as it is unreliable and fails inte

RFR 8020758: HttpCookie constructor does not throw IAE when name contains a space

Mark, Michael, java.net.HttpCookie, rightly or wrongly, supports three different Cookie specifications. Some of these are conflicting, and there have been many many bugs reported against various "special" characters being accepted. This one is hopefully straight forward. The issue is specific

hg: jdk8/tl/jdk: 8020758: HttpCookie constructor does not throw IAE when name contains a space

Changeset: f120672b91ef Author:chegar Date: 2013-10-23 14:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120672b91ef 8020758: HttpCookie constructor does not throw IAE when name contains a space Reviewed-by: michaelm, msheppar ! src/share/classes/java/net/HttpCookie.java

Re: RFR: JDK-7122887 - JDK ignores Gnome3 proxy settings

Hi Dan, Firstly, thank you for working on this. This is really useful, and I'm glad to see it going into JDK 8. I grabed the patch and built it. All looks fine, and the updates you added to the manual test are really useful to verify the implementation. All in all I'm happy with this change

Re: RFR: JDK-7122887 - JDK ignores Gnome3 proxy settings

dxu/7122887/webrev.01/>. Thanks! Looks good to me Dan. -Chris. -Dan On 10/23/2013 11:28 AM, Dan Xu wrote: You are right, Chris. The java class objects initialization should be in the init method. I will update it now. Thanks for the review! -Dan On 10/23/2013 11:21 AM, Chris Hegarty wrot

Re: ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

The changes, to remove this test from the problem list, look fine to me. I see that JDK-7079145 has been closed. We should probably re-open it, and use it to push these changes. I can sponsor this change for you. -Chris. On 10/24/2013 03:58 AM, Eric Wang wrote: Hi, This is a review request

hg: jdk8/tl/jdk: 7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt

Changeset: d126301ad372 Author:ewang Date: 2013-10-25 11:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d126301ad372 7079145: Remove java/net/ipv6tests/UdpTest.java from the ProblemList.txt Reviewed-by: alanb, chegar ! test/ProblemList.txt

Re: HttpURLConnection with IPv6 link-local address

Hi Bruno, Wow, I've been working in this area for more than a decade, and this is the first bug I've seen on the HttpURLConnection when using URL's with literal IPv6 addresses. That said, I think your points are valid. I created the following bug to track this issue: https://bugs.openjdk.

RFR 8026880: NetworkInterface native initializing code should check fieldID values

This is a trivial change, good practice, to check return values from GetFieldID, and friends. I've taken a quick look over the networking native code and see no other similar issues. http://cr.openjdk.java.net/~chegar/8026880/webrev.00/ -Chris.

Re: RFR 8026880: NetworkInterface native initializing code should check fieldID values

On 10/29/2013 05:00 PM, Alan Bateman wrote: On 29/10/2013 16:56, Chris Hegarty wrote: This is a trivial change, good practice, to check return values from GetFieldID, and friends. I've taken a quick look over the networking native code and see no other similar issues.

hg: jdk8/tl/jdk: 8027466: Revert jdk/THIRD_PARTY_README to known good version

Changeset: 121c34517841 Author:chegar Date: 2013-10-29 17:21 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/121c34517841 8027466: Revert jdk/THIRD_PARTY_README to known good version Reviewed-by: alanb ! THIRD_PARTY_README

hg: jdk8/tl/jdk: 8026880: NetworkInterface native initializing code should check fieldID values

Changeset: 9a5048dc7c0d Author:chegar Date: 2013-10-30 14:41 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9a5048dc7c0d 8026880: NetworkInterface native initializing code should check fieldID values Reviewed-by: alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/w

Re: RFR: 8027570 NullPointerException in URLPermission.hashCode()

Looks good to me Michael. Trivially, the test could include this bug number in its @bug tag. -Chris > On 30 Oct 2013, at 16:51, Michael McMahon > wrote: > > Interesting little bug this one. The precedence rules > were overlooked and the expected result of an expression evaluation > wasn't wha

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

behavior for Teredo Tunneling Interface, based on the discussion with Chris Hegarty, we decided to fix this test with removing "Windows && Teredo Tunneling Pseudo-Interface" from this test. Please let me know if you have any comments or suggestions. Thank you Tristan /Tri

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

Looks good to me Michael. Trivially, I'd replace 'new String(sb)' with 'sb.toString()' in HostPortrange, but that's just me. -Chris. On 01/11/2013 14:46, Michael McMahon wrote: Simple bug fix to new URLPermission class, caused by insufficient parameter checking of the constructor. webrev: h

Re: RFR 8027687: The constructors of URLPermission class do not behave as described in javadoc

The latest changes look better to me. Trivially ( and in agreement with Vitaly ), I would, but you don't have to, change: static final int CAP_DIFF = 0x20; // 'a' - 'A'; static String toLowerCase(String s) { final int len = s.length(); StringBuilder sb = null;

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

Since windows API has very inconsistent behavior on Teredo Tunneling Pesudo-Interface, we removed this network interface for this test. Thank you. Tristan On 01/11/2013 22:43, Chris Hegarty wrote: Hi Tristan, From what I understand of the issue I see no problem with what you are suggesting. W

RFR: Inet[4|6]Address native initializing code should check fieldID values

Another installment of checks for return values from GetFieldID, and friends, to follow up on last weeks work [1]. http://cr.openjdk.java.net/~chegar/netNullChecks/webrev/ There are more cleanups to come along the same lines, but I'd like to keep these changes small and confined for now. -Chr

Re: RFR: Inet[4|6]Address native initializing code should check fieldID values

> On 5 Nov 2013, at 20:39, Michael McMahon wrote: > >> On 05/11/13 19:38, Chris Hegarty wrote: >> Another installment of checks for return values from >> GetFieldID, and friends, to follow up on last weeks work [1]. >> >> http://cr.openjdk.java.net/~chega

Re: RFR: Inet[4|6]Address native initializing code should check fieldID values

k ok to me; not a Reviewer) Thanks for the review Roger. -Chris. > > Roger > >> On 11/5/2013 3:39 PM, Michael McMahon wrote: >>> On 05/11/13 19:38, Chris Hegarty wrote: >>> Another installment of checks for return values from >>> GetFie

hg: jdk8/tl/jdk: 8027822: ProblemList.txt Updates (11/2013)

Changeset: f37d62e295c0 Author:chegar Date: 2013-11-07 08:04 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f37d62e295c0 8027822: ProblemList.txt Updates (11/2013) Reviewed-by: chegar, alanb Contributed-by: Amy Lu ! test/ProblemList.txt

hg: jdk8/tl/jdk: 8027961: Inet[4|6]Address native initializing code should check field/MethodID values

Changeset: 82b276590b85 Author:chegar Date: 2013-11-07 08:23 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82b276590b85 8027961: Inet[4|6]Address native initializing code should check field/MethodID values Reviewed-by: michaelm, rriggs ! src/share/native/java/net/Inet4Addr

Re: RFR: 8027221 test/java/net/URLPermission/nstest/LookupTest.java failing intermittently, output insufficient

Looks ok to me. -Chris. On 11/07/2013 09:31 AM, Michael McMahon wrote: This is a test fix. The test currently uses a fixed port number (in the policy file and Java test) We need to change to use a shell script so that a port can be chosen dynamically and the appropriate policy file created. T

RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

Virus checkers and, on more modern Windows OSes, Windows Experience Service, and other external processes, have been causing trouble when it comes to tests deleting files. On a number of occasions in the past retry logic has been added to tests that need to delete files. Also, the jtreg harnes

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

d highlight the difference between these methods and regular delete. So maybe move to public deleteWithRetry? -Chris. Michael On 07/11/13 10:05, Chris Hegarty wrote: Virus checkers and, on more modern Windows OSes, Windows Experience Service, and other external processes, have been causing

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

ING 4) Use SimpleFileVisitor, rather than FileVisitor Thanks, -Chris. On 11/07/2013 01:24 PM, Alan Bateman wrote: On 07/11/2013 11:34, Chris Hegarty wrote: : I've also received another comment offline about the method names. They should be more descriptive, and highlight the difference between these meth

RFR 8019834: InetAddress.getByName should always throw UHE for bad IPv6 literals

This is an interesting little product bug that was originally thought to be a test stabilization issue, with java/net/ipv6tests/BadIPv6Addresses.java. Depending on the input/configuration/patch level getaddrinfo may try to lookup a malformed IPv6 literal, and block for several seconds waiting

Re: RFR 8019834: InetAddress.getByName should always throw UHE for bad IPv6 literals

On 08/11/2013 13:15, Alan Bateman wrote: ... http://cr.openjdk.java.net/~chegar/8019834/webrev.00/ This looks okay to me. You might want to adjust the bug summary slightly as UHE for bad IPv6 literal addresses is correct (it's just the hang due to the lookup). Thanks Alan, I'll update the sy

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

leUtils.02/webrev/ Thanks, -Chris. On 08/11/2013 02:26, Dan Xu wrote: On 11/07/2013 11:04 AM, Alan Bateman wrote: On 07/11/2013 14:59, Chris Hegarty wrote: Given both Michael and Alan's comments. I've update the webrev: http://cr.openjdk.java.net/~chegar/fileUtils.01/webrev/

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

Roger On 11/8/2013 9:47 AM, Chris Hegarty wrote: Alan, > An alternative might be to just throw the IOException with > InterruptedException as the cause. Perfect. Updated in the new webrev. Dan, You are completely correct. I was only catering for the case where "java.nio.file.FileS

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

I have not seen any objections, so I will push this for you. -Chris. On 08/11/2013 14:18, Tristan Yan wrote: Hi Chris I didn't this has been pushed, can you sponsor this for me. Thank you so much Tristan On Nov 5, 2013, at 2:40 AM, Chris Hegarty mailto:chris.hega...@oracle.com>> w

hg: jdk8/tl/jdk: 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface

Changeset: 3112729d6b74 Author:tyan Date: 2013-11-08 15:12 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3112729d6b74 8022963: java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface Reviewed-by: chegar ! test/java/net/MulticastSocket/TestInterfac

hg: jdk8/tl/jdk: 8019834: InetAddress.getByName hangs for bad IPv6 literals

Changeset: 771c77b49bb6 Author:chegar Date: 2013-11-08 15:15 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771c77b49bb6 8019834: InetAddress.getByName hangs for bad IPv6 literals Reviewed-by: alanb ! src/share/classes/java/net/InetAddress.java ! test/java/net/ipv6tests/BadI

Re: RFR for JDK-8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine

Looks fine to me Tristan, I'll sponsor this change for you. Trivially, I will add a 30sec timeout to the wait, just in case there is a problem in the future. -Chris. On 11/04/2013 03:12 AM, Tristan Yan wrote: Hi Everyone Please review the fix for JDK-8023462

hg: jdk8/tl/jdk: 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine

Changeset: 46982ca895b4 Author:tyan Date: 2013-11-08 18:54 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46982ca895b4 8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine Reviewed-by: chegar ! test/com/sun/net/httpserver/bugs/

Re: 8028074: InetAddress.getByName fails with UnknownHostException: invalid IPv6 address if host name starts with a-f

The change looks good to me. Thanks for spotting this and jumping on it so quickly. -Chris. On 08/11/2013 20:39, Alan Bateman wrote: There's a small problem with the fix for JDK- 8019834 that was pushed to jdk8/tl today. The patch means that UHE is thrown when doing a lookup of hosts that sta

hg: jdk8/tl/jdk: 8028102: All test targets, jdk/test/Makefile, fail on Windows

Changeset: b48eded97dff Author:chegar Date: 2013-11-11 10:33 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b48eded97dff 8028102: All test targets, jdk/test/Makefile, fail on Windows Reviewed-by: mduigou ! test/Makefile

Re: RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

9 99Thread.sleep(RETRY_DELETE_MILLIS); seems not indented correctly. Thanks, -Dan On 11/08/2013 07:35 AM, Chris Hegarty wrote: On 08/11/2013 15:01, roger riggs wrote: Hi, Does renaming the file/directory suffer the same delay? I have not tried, but I read that MoveFileEx does not suffer

Re: RFR for JDK-8022212 Intermittent test failures in java/net

On 11/13/2013 06:00 AM, Tristan Yan wrote: Hi Everyone I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212. This is the same root cause as bug JDK-8022963, which is we should not test "Teredo Tunneling Pseudo-Interface " interface in windows. So suggested fix is doing the same

hg: jdk8/tl/jdk: 8022213: Intermittent test failures in java/net/URLClassLoader

Changeset: 70f1bed5e7fd Author:chegar Date: 2013-11-13 16:44 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70f1bed5e7fd 8022213: Intermittent test failures in java/net/URLClassLoader Reviewed-by: dxu, alanb ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java

Re: RFR for JDK-8022212 Intermittent test failures in java/net

Thank you Tristan. I can sponsor this change for you. -Chris. On 13/11/13 12:53, Tristan Yan wrote: Thank you Chris This is the webrev http://cr.openjdk.java.net/~ewang/tristan/JDK-8022212/webrev.00/ Thank you Tristan On 11/13/2013 06:07 PM, Chris Hegarty wrote: On 11/13/2013 06:00 AM

Re: RFR for JDK-7086879 java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled

I haven't seen a follow up on this, so I think we can just go ahead and remove the test from the ProblemList.txt for now, and revisit, if necessary. Tristan, I can sponsor this for you. -Chris. On 11/14/2013 02:59 PM, Tristan Yan wrote: Hi Everyone I am working on https://bugs.openjdk.java.n

hg: jdk8/tl/jdk: 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled

Changeset: d5ddde25d107 Author:tyan Date: 2013-11-19 13:46 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5ddde25d107 7086879: java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled Reviewed-by: chegar ! test/ProblemList.txt

hg: jdk8/tl/jdk: 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves "sleep 6666" processes behind

Changeset: cfbee8ee71bf Author:bvaidya Date: 2013-11-19 15:31 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cfbee8ee71bf 8028094: TEST_BUG: java/lang/ProcessBuilder/Basic.java leaves "sleep " processes behind Reviewed-by: chegar ! test/java/lang/ProcessBuilder/Basic.ja

Re: RFR for JDK-8027901 Intermittent test failure java/net/ProxySelector/MultiThreadedSystemProxies.java

Charlie, When I run this test with DISPLAY unset, or set to , and on a system without the latest Gnome 3 libraries ( more specifically NOT having libgio-2.0.so ), I get a warning that GConf cannot be initialized (see below). I do not see this test hanging. --- (process:25718): GConf-WARNING

Re: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

On 20/11/13 10:19, Daniel Fuchs wrote: Hi Tristan, I believe you should also declare the 'error' flag as well as the 'clientCtx' variable volatile since they are set by a thread and read by another. Good catch Daniel. Tristan, can you update the webrev and create a changeset. I can then spons

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 2972241cf7eb Author:tyan Date: 2013-11-21 13:37 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2972241cf7eb 703: test/com/sun/net/httpserver/Test9a.java fails intermittently Summary: Additional stacktrace information is printed on failure Reviewed-by: alanb, df

Re: 答复: RFR for JDK-8022212 Intermittent test failures in java/net

M 收件人: Chris Hegarty; net-dev@openjdk.java.net 主题: 答复: RFR for JDK-8022212 Intermittent test failures in java/net Thanks Chris for sponsoring this. Tristan -邮件原件- 发件人: Chris Hegarty 发送时间: Thursday, November 14, 2013 9:34 PM 收件人: Tristan Yan; net-dev@openjdk.java.net 主题: Re: RFR for JDK-80

hg: jdk8/tl/jdk: 8029348: ProblemList.txt updates (11/2013)

Changeset: 5bcaf730ceb8 Author:tyan Date: 2013-11-29 09:29 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8 8029348: ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt

Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

Looks good to me Mark. -Chris. On 02/12/13 12:35, Mark Sheppard wrote: Hi based on feedback the changes for issue: https://bugs.openjdk.java.net/browse/JDK-8025211 have been amended to the following: http://cr.openjdk.java.net/~msheppar/8025211/webrev.02/ please oblige and review regards

Re: RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname

This update looks much better to me. -Chris. On 02/12/13 14:33, Michael McMahon wrote: On 02/12/13 12:40, Alan Bateman wrote: On 02/12/2013 12:22, Michael McMahon wrote: Okay. I think the best approach is to recognise the userinfo but just remove it when constructing URLPermissions thereby ef

Re: [OpenJDK 2D-Dev] RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX

On 26 Nov 2013, at 18:08, Iris Clark wrote: >> So overall it looks good to me and should be pushed to the staging > forest >> once you hear from others that commented previously. > > I think that means Chris Hegarty, Michael McMahon, and Sergey Bylokhov. > Alan,

hg: jdk8/tl/jdk: 8029141: Add @FunctionalInterface annotation to Callable interface

Changeset: 2a6611ebfb6c Author:smarks Date: 2013-12-04 18:02 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a6611ebfb6c 8029141: Add @FunctionalInterface annotation to Callable interface Reviewed-by: chegar, alanb ! src/share/classes/java/util/concurrent/Callable.java

Re: Strange Issue With Static Global Variable in Native

On 07/12/2013 18:12, Dan Xu wrote: ... Just so I understand, did you use a JNI global when caching the reference? -Alan Hi Alan, What is a JNI global? http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1242 > What I use here is a static global variable. I have u

Re: Strange Issue With Static Global Variable in Native

On 08/12/13 17:39, Dan Xu wrote: On 12/08/2013 01:34 AM, Chris Hegarty wrote: On 07/12/2013 18:12, Dan Xu wrote: ... Just so I understand, did you use a JNI global when caching the reference? -Alan Hi Alan, What is a JNI global? http://docs.oracle.com/javase/7/docs/technotes/guides/jni

Re: RFR: JDK-8025437 - Check DefaultProxySelector for JNI pending exception issues

Looks good to me. Thanks Dan. -Chris. On 12 Dec 2013, at 05:14, Dan Xu wrote: > Hi All, > > Please review the fix for the JNI pending exception issue in > src/solaris/native/sun/net/spi/DefaultProxySelector.c. I have refactored the > code so that JNI calls will only be run when previous JNI

Re: RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

On 18 Dec 2013, at 15:13, Alan Bateman wrote: > On 18/12/2013 15:09, Mark Sheppard wrote: >> >> Hi, >> please oblige and review the following changes >> >> http://cr.openjdk.java.net/~msheppar/7102702/webrev/ > Good sleuthing!! The change looks good to me. Yes, this is a good find, and the c

Re: RFR: simple javadoc cleanup in java.net

On 18 Dec 2013, at 14:35, roger riggs wrote: > Thanks Alan, > > I corrected the webrev to link both locations that refer to ProxySelector. > http://cr.openjdk.java.net/~rriggs/webrev-javadoc-link-7018010/ Looks good. Thanks Roger. -Chris. > > Roger > > On 12/18/2013 6:23 AM, Alan Bateman

Re: RFR:JDK-7102702 - java/net/PortUnreachableException/OneExceptionOnly.java failing

t; regards > Mark > > On 18/12/2013 16:05, Chris Hegarty wrote: >> On 18 Dec 2013, at 15:13, Alan Bateman wrote: >> >>> On 18/12/2013 15:09, Mark Sheppard wrote: >>>> Hi, >>>> please oblige and review the following changes >>>> &

hg: jdk8/tl/jdk: 2 new changesets

Changeset: e2bdddb8bedf Author:dl Date: 2013-12-19 10:31 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2bdddb8bedf 8026155: Enhance ForkJoin pool Reviewed-by: chegar, alanb, ahgross ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/co

Re: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

On 23 Dec 2013, at 18:21, Mark Sheppard wrote: > Hi, > Please oblige and review the following changes: > > http://cr.openjdk.java.net/~msheppar/8027903/webrev/ > > which address the issue: > > https://bugs.openjdk.java.net/browse/JDK-8027903 > > The test failure was found to be due to an in

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

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 first glance they look right to me. I will also look to see if the test can be reduced a little, and add appropriate jtreg tags (

Re: RFR: java/net/MulticastSocket/SetGetNetworkInterfaceTest.java throws java.net.SocketException: Cannot assign requested address

Thanks Mark, On 2 Jan 2014, at 16:26, Mark Sheppard wrote: > Hi Alan, > added an ExceptionDescribe to native code and an -Xcheck:jni to the cmd line > options to produce the > following: > > WARNING in native method: JNI call made with exception pending >at java.net.PlainDatagramSocke

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 18080cca998a Author:dl Date: 2014-01-03 06:22 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Chan

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

ny special handling for SkipException in the jtreg source. I also cannot find any use of it in the any of the OpenJDK JDK 9 repositories. Maybe just to be safe you could print a warning message and simply return? -Chris. On Mon, Jan 6, 2014 at 6:16 PM, Chris Hegarty mailto:chris.hega...@

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

On 06/01/14 16:05, Dimitar Mavrodiev wrote: The jtreg version I am using(4.1 fcs b05) seems to be correctly handling it. What jtreg version should I be using? See https://bugs.openjdk.java.net/browse/JDK-8026362 for a an example of this. Did you try to run your test without ::1 enabled? -Ch

Re: JDK 9 RFR of JDK-8031201: Fix casting lint issues in java.net

Looks good to me Joe. -Chris. On 6 Jan 2014, at 19:36, Joe Darcy wrote: > Hello, > > Please review the simple patch below to address > > JDK-8031201: Fix casting lint issues in java.net > > (The various ObjectInputStream.GetField.get methods which have a default > parameter, have an pro

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

The source changes look good to me too. I see Alan has commented on the test, and I agree. Trivially, can you also remove the dependency on the old internal HttpServer, and use the newer com.sun.net.httpserver API. It is easier to user, and more robust. You can see an example here [1]. -Chri

Re: JDK 9 RFR of 8031326: Use Class rather than Class in java.net method signatures

Approved. -Chris. On 7 Jan 2014, at 17:36, Joe Darcy wrote: > Hello, > > Please review these changes to remove use of raw Class in some method > signatures in java.net: > >JDK-8031326: Use Class rather than Class in java.net method > signatures > > Patch below. > > Thanks, > > -J

Re: RFR: (8030875) Macros for checking and returning on exceptions

Thank you Roger, much appreciated. I think Dan has a change in flight that could be simplified a bit by using these. -Chris. On 10/01/14 15:37, roger riggs wrote: Please review: To enable native code checking consistently for thrown exceptions, the macros in net_util.h and java/util/jar/pac

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

ust to verify it, then obviously forgot it was an internal link. Sorry about this. I’ll repost a mail when the public server is back online. -Chris. > > Thanks, > Dimitar > > Sent from my mobile device. > > On Jan 13, 2014 9:11 PM, "Chris Hegarty" wrote: > Hi Di

  1   2   3   4   5   6   7   8   9   10   >