hg: jdk8/tl/jdk: 8023130: (process) ProcessBuilder#inheritIO does not work on Windows

Changeset: 56d247821694 Author:alanb Date: 2013-09-23 04:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56d247821694 8023130: (process) ProcessBuilder#inheritIO does not work on Windows Reviewed-by: alanb, martin Contributed-by: ivan.gerasi...@oracle.com ! src/windows/nat

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

On 01/10/2013 11:31, Brian Burkhalter wrote: Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.ope

hg: jdk8/tl: 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification

Changeset: 187a759c08ba Author:alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/187a759c08ba 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Reviewed-by: mduigou, tbell ! common/makefile

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

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 This looks better, although I think I wou

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

On 02/10/2013 12:40, Brian Burkhalter wrote: : 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. It's very possible the retry will fail the same way

hg: jdk8/tl/jdk: 8025983: Typo in Javadoc of Files.isRegularFile()

Changeset: 0ac9dc315071 Author:alanb Date: 2013-10-07 11:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ac9dc315071 8025983: Typo in Javadoc of Files.isRegularFile() Reviewed-by: mchung, chegar ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/fil

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

On 08/10/2013 00:00, Brian Burkhalter wrote: Resuming this discussion … Thanks for the previous comments. My feeling at this point is to do one of two things: A) defer to something after JDK 8, or B) on EAI_AGAIN do not retry but set the cause of the UAE to "new SomeException(gai_strerror(err

hg: jdk8/tl/jdk: 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers

Changeset: 95bb56c61276 Author:alanb Date: 2013-10-08 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95bb56c61276 8024788: (fs) Files.readAllBytes uses FileChannel which may not be supported by all providers Reviewed-by: chegar ! src/share/classes/java/nio/file/Files.

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

This looks like one for the net-dev list. On 09/10/2013 09:10, 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 the leak was eliminated. I couldn't ever reproduce the failure even

hg: jdk8/tl/jdk: 8008662: Add @jdk.Exported to JDK-specific/exported APIs

Changeset: 2ea162b2ff55 Author:alanb Date: 2013-10-09 09:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ea162b2ff55 8008662: Add @jdk.Exported to JDK-specific/exported APIs Reviewed-by: chegar, vinnie, dfuchs, mchung, mullan, darcy ! src/share/classes/com/sun/jdi/AbsentI

hg: jdk8/tl/jdk: 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing

Changeset: 99b7bbe0474f Author:dl Date: 2013-10-10 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99b7bbe0474f 7011859: java/util/concurrent/Semaphore/RacingReleases.java failing Reviewed-by: alanb, dholmes ! src/share/classes/java/util/concurrent/locks/AbstractQueued

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

On 10/10/2013 11:10, Michael McMahon wrote: Can I get the following change for jdk 8 reviewed please? It's a simple build change to enable compilation of the dummy SCTP API layer on macosx, plus the dummy implementation used on windows. The existing jdk_sctp tests cover this. http://cr.openjdk

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

On 09/10/2013 19:16, Brian Burkhalter wrote: : I have created a simple implementation for option B: http://cr.openjdk.java.net/~bpb/8010371/webrev.3/ I should note that the Unix Inet6 implementation was already using the call ThrowUnknownHostExceptionWithGaiError() to generate the UHE so in th

hg: jdk8/tl/jdk: 8019526: (fs) Files.lines, etc without Charset parameter

Changeset: 9632de07d963 Author:alanb Date: 2013-10-11 20:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9632de07d963 8019526: (fs) Files.lines, etc without Charset parameter Reviewed-by: psandoz, henryjen ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/F

Re: Fix for JDK-8023555

On 12/10/2013 13:33, Tristan Yan wrote: Please review fix for JDK-8023555 http://cr.openjdk.java.net/~pzhang/Tristan/webrev/ Thanks Skipping the test when configured to be the loopback seems reasonable to me too. A minor comment on th

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

On 10/10/2013 21:24, Brian Burkhalter wrote:On 10/10/2013 21:24, Brian Burkhalter wrote: : Assuming that the general idea is correct, there are a few possible alternatives for a final version for Windows. I am not concerned in this discussion about picky details including naming which can be fi

hg: jdk8/tl/jaxp: 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc

Changeset: de8c803d4958 Author:aefimov Date: 2013-10-13 13:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/de8c803d4958 8008733: Psr:perf:osb performance regression (18%) in wss_bodyenc Reviewed-by: alanb, shade ! src/com/sun/org/apache/xpath/internal/XPathContext.java

hg: jdk8/tl/jdk: 8026398: Can't load jdk.Exported, ClassNotFoundException

Changeset: 0b6632e570b0 Author:alanb Date: 2013-10-15 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0b6632e570b0 8026398: Can't load jdk.Exported, ClassNotFoundException Reviewed-by: chegar, mchung ! make/tools/src/build/tools/buildmetaindex/BuildMetaIndex.java

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

On 14/10/2013 20:43, Brian Burkhalter wrote: : Here's the patch updated for this option: http://cr.openjdk.java.net/~bpb/8010371/webrev.4/ I think this is okay, the only concern is that the host name is no longer guaranteed to be in the

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

On 15/10/2013 15:05, Rob McKenna wrote: Hi folks, Looking for a review for the following: http://cr.openjdk.java.net/~robm/8026245/webrev.01/ It seems there were a number of issues with the original fix for 7180557. This patch resolves those: - No existing net tests exercised the ipv4 only

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

On 15/10/2013 16:28, Brian Burkhalter wrote: The hostname is guaranteed to be in the exception detail: void NET_ThrowByNameWithLastError(JNIEnv *env, const char *name, const char *defaultDetail) { char errmsg[255]; sprintf(errmsg, "errno: %d, error: %s\n", WSAGetLastE

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

On 17/10/2013 00:21, Brian Burkhalter wrote: Dmitry, I think you are correct: that slipped by both me and the reviewers. I have reopened the issue and posted an amendment to the original webrev here: http://cr.openjdk.java.net/~bpb/8010371/webrev.4-amendment/ I've restored the bug fields and

Re: JDK 8 RFR 8026806: Incomplete test of getaddrinfo() return value could lead to incorrect exception for Windows Inet 6

On 18/10/2013 00:10, Dmitry Samersoff wrote: Brian, Looks good for me (not a reviewer). -Dmitry I'm okay with it too (apologies we didn't catch it in the 10-iteration first round, I'm sure it slipped in during one of those iterations). -Alan.

hg: jdk8/tl/jdk: 3 new changesets

Changeset: da695008417f Author:alanb Date: 2013-10-18 13:45 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da695008417f 8026859: (fs) test/java/nio/file/Files/StreamTest.java fails to compile intermittently Reviewed-by: psandoz ! test/java/nio/file/Files/StreamTest.java Ch

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 602aa6fa46c6 Author:alanb Date: 2013-10-18 15:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/602aa6fa46c6 8026876: (fs) Build issue with src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java Reviewed-by: psandoz ! src/solaris/classes/sun/nio/

hg: jdk8/tl/corba: 8021257: com.sun.corba.se.** should be on restricted package list

Changeset: 52ad44f9a3ec Author:alanb Date: 2013-10-22 11:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/52ad44f9a3ec 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks Contributed-by: alan.bate...@oralce.com, mark.shepp

hg: jdk8/tl/jdk: 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly

Changeset: f15ad52cffed Author:alanb Date: 2013-10-22 12:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f15ad52cffed 8024833: (fc) FileChannel.map does not handle async close/interrupt correctly Reviewed-by: alanb Contributed-by: chris.w.den...@gmail.com ! src/share/class

hg: jdk8/tl/jdk: 8021257: com.sun.corba.se.** should be on restricted package list

Changeset: 6f9515a9519f Author:alanb Date: 2013-10-22 11:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f9515a9519f 8021257: com.sun.corba.se.** should be on restricted package list Reviewed-by: chegar, coffeys, smarks, mullan Contributed-by: alan.bate...@oralce.com, mark

hg: jdk8/tl/jdk: 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win)

Changeset: 54869853c06c Author:alanb Date: 2013-10-22 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54869853c06c 7074436: (sc) SocketChannel can do short gathering writes when channel configured blocking (win) Reviewed-by: chegar ! src/windows/native/sun/nio/ch/Socke

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

On 24/10/2013 03:59, Eric Wang wrote: On 2013/10/24 10:57, Eric Wang wrote: Hi, This is a review request to remove the test java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test tracked by JDK-7079145 is hung if linux kernel is 2.6

hg: jdk8/tl/jdk: 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable

Changeset: 700d62b8d9cc Author:alanb Date: 2013-10-24 13:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/700d62b8d9cc 8026344: j.u.c.a *Adder and *Accumulator extend a package private class that is Serializable Reviewed-by: rriggs, psandoz, chegar Contributed-by: d...@cs.o

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

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. http://cr.openjdk.java.net/~chegar/8026880/webrev.00/ This looks ok

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

On 29/10/2013 17:11, Chris Hegarty wrote: D'oh, I spent too much time looking for other places where this was missing, and I forgot about src/windows! Updated webrev: http://cr.openjdk.java.net/~chegar/8026880/webrev.01/ This looks okay to me. -Alan

Re: URGENT - In correct push Fwd: [JBS] (JDK-8025198) Intermittent test failure: java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java

On 04/11/2013 12:10, David Holmes wrote: My commit pulled in a bunch of local changes that should never have been pushed (the import commit failed due to whitespace and when I re-issued the commit I didn't restrict it to the single test file). Can anyone roll this back on the actual server? It

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

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 methods and regular delete. So maybe move to public deleteWithRetry? That might be a bit better as otherwi

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

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/ 1) more descriptive method names 2) deleteXXX methods return if interrupted, leaving the interrupt status set 3) Use Files.copy w

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

On 08/11/2013 11:32, Chris Hegarty wrote: 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 lite

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

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 start with a-f. I ran into it because I happen to be on a machine that starts with "a" :-) I'd like to get a patch into jdk8/tl quickly

hg: jdk8/tl/jdk: 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f

Changeset: 50df04934e86 Author:alanb Date: 2013-11-08 21:07 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/50df04934e86 8028074: InetAddress.getByName fails with UHE "invalid IPv6 address" if host name starts with a-f Reviewed-by: chegar ! src/share/classes/java/net/InetAdd

hg: jdk8/tl/jdk: 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS

Changeset: 9130770fb6e3 Author:alanb Date: 2013-11-09 16:46 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9130770fb6e3 8028044: [TEST_BUG] Calendar shell tests do not pass TESTVMOPTS Reviewed-by: dholmes, alanb Contributed-by: patrick.zh...@oracle.com ! test/java/util/Calen

Re: qualified host parameter for UnknownHostException?

On 08/11/2013 21:34, Bernd Eckenfels wrote: Hello, BTW: it would be good if UHE had a data member of the not-found host value. Actually the javadoc hints in that direction: # public UnknownHostException(String host) # # Parameters: #host - the detail message. which is quite confusing. Ma

hg: jdk8/tl/jdk: 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win)

Changeset: 2525b91ca5a6 Author:alanb Date: 2013-11-11 08:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2525b91ca5a6 8028099: Many com/sun/management/OperatingSystemMXBean tests failing with CCE (win) Reviewed-by: mchung ! src/windows/classes/sun/management/OperatingSyst

Re: RFR: 8028060 test/java/net/URLPermission/nstest/lookup.sh failing (win)

On 11/11/2013 15:37, Michael McMahon wrote: This is a fix to a test case that is failing on Windows. A couple of problems: 1) cygwin doesn't like the newline at the end of the port number that gets printed to System.out 2) the calling script was not setting the classpath separator correctly

hg: jdk8/tl/jdk: 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win)

Changeset: 0c414ac10700 Author:alanb Date: 2013-11-12 17:37 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c414ac10700 8028208: (aio) Assertion in clearPendingIoMap when closing at around time file lock is acquired immediately (win) Reviewed-by: chegar ! src/windows/classe

hg: jdk8/tl/jdk: 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError

Changeset: c4c84b5a3dfa Author:alanb Date: 2013-11-13 07:43 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c4c84b5a3dfa 8028239: test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh with NoClassDefFoundError Reviewed-by: mchung, egahlin ! test/sun/jvmstat/monitor

hg: jdk8/tl/jdk: 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission

Changeset: a493871959c2 Author:alanb Date: 2013-11-13 16:52 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a493871959c2 8028270: Files.readSymbolicLink calls AccessController directly so security manager can't grant the permission Reviewed-by: mchung, martin, chegar ! src/s

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

Changeset: ecf85f4aecf0 Author:alanb Date: 2013-11-14 10:40 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecf85f4aecf0 8028343: More ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt

hg: jdk8/tl/jdk: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests

Changeset: 2e574350a2b6 Author:alanb Date: 2013-11-19 14:08 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2e574350a2b6 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! test/Makefile

hg: jdk8/tl: 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests

Changeset: 9937f406e27e Author:alanb Date: 2013-11-19 14:11 + URL: http://hg.openjdk.java.net/jdk8/tl/rev/9937f406e27e 8028478: Re-visit JPRT testsets to make it easier to run subsets of the tests Reviewed-by: dholmes, sla, tbell ! make/jprt.properties ! test/Makefile

Re: RFR 8028581: [TESTBUG] java/net/Socket/LingerTest.java failing

On 19/11/2013 15:18, Michael McMahon wrote: This is a test that just failed recently on Windows, probably due to a timing issue. The critical time delay in the test is increased from 5 seconds to 10 seconds and some extra printlns are added to show the exact sequence in case it fails again. h

hg: jdk8/tl/jdk: 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures

Changeset: 36821ee241a2 Author:alanb Date: 2013-11-19 15:09 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36821ee241a2 8028589: Instrument tools/jar/JarEntryTime.java to make it easier to diagnose failures Reviewed-by: chegar ! test/tools/jar/JarEntryTime.java

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

On 20/11/2013 04:59, Tristan Yan wrote: /Hi All/ /I am working on https://bugs.openjdk.java.net/browse/JDK-703, this bug was opened 3 years ago and test was put into ProblemList. I ran a 1000 times loop to try to reproduce the failure but I got no luck. Also I use same jdk binaries run a

hg: jdk8/tl/jdk: 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone

Changeset: ecd6c25b54ce Author:alanb Date: 2013-11-20 21:34 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecd6c25b54ce 8028734: test/java/util/Locale/InternationalBAT.java changes does not restore the default TimeZone Reviewed-by: naoto ! test/java/util/Locale/Internationa

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

On 20/11/2013 18:26, Volker Simonis wrote: Hi, this is the second review round for "8024854: Basic changes and files to build the class library on AIX ". The previous reviews can be found at the end of this mail in the references section. I'

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

On 21/11/2013 15:54, Volker Simonis wrote: : But actually I've just realized that it is not need at all, because 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be probably called a feature of the new file layout:) So I'll simply change it to: 48 ifeq ($(OPENJDK_TARGE

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

On 26/11/2013 16:23, Volker Simonis wrote: Hi, thanks to everybody for the prompt and helpful reviews. Here comes the final webrev which incorporates all the corrections and suggestions from the second review round: http://cr.openjdk.java.net/~simonis/webrevs/8024854.v3/ I've successfully buil

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

On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machine

Re: RFR: 8029127: A redirect POST request does not work and illegalStateException on HttpURLConnection.getInputStream

On 29/11/2013 18:03, Michael McMahon wrote: This is another regression in JDK 8. A new "connecting" flag is getting confused when a redirect occurs and a POST gets converted to a GET. http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/ The change looks okay but I do have a few comments on t

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

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 effectively ignoring it. This is what the http protocol handler (and other support classes) have been doing all the time since th

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

On 02/12/2013 14:33, Michael McMahon wrote: The second webrev is at link below. This is somewhat simpler now. I think it still needs a spec change though. So, I would like to propose that to the CCC asap. http://cr.openjdk.java.net/~michaelm/8029354/webrev.2/ I added a test that uses the prot

Re: Strange Issue With Static Global Variable in Native

On 07/12/2013 01:22, Dan Xu wrote: Hi All, When working on src/solaris/native/sun/net/spi/DefaultProxySelector.c, previously I tried to cached a jobject (The cached java object is java.net.Proxy.NO_PROXY, which is a special type of Proxy.) as a global static variable, no_proxy, in this c file

Re: RFR: simple javadoc cleanup in java.net

On 18/12/2013 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. -Alan

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

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. -Alan.

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

On 18/12/2013 16:19, Mark Sheppard wrote: potentially the same issue with TwoStacksPlainDatagramSocketImpl for an IPV6 address. as I have only ever enabled TwoStack via -Djava.net.preferIPv4Stack=true then the sockaddr_in is sufficient to hold an IPV4 address If we think it worthwhile, I can

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

On 23/12/2013 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 interface configured with

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

On 02/01/2014 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: Thanks, it is clearer now. What you have is okay but I guess I'm just concerned that mcast_set_if_by_if_v4 can potentially fail

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

On 03/01/2014 11:04, Dimitar Mavrodiev wrote: Greetings all, I've fixed this and created a test to cover it, is there a sponsor who could push this through? Here's a link to the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/index.html. It's a simple fix that correctly cons

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

On 06/01/2014 19:36, Joe Darcy wrote: Hello, Please review the simple patch below to address JDK-8031201: Fix casting lint issues in java.net This looks okay to me. -Alan

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

On 06/01/2014 15:21, Dimitar Mavrodiev wrote: Thanks, Chris. I've removed the dependency on the internal HttpServer. Here's another webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/2/index.html. I'm not 100% sure how jtreg handles TestNG tests throwing SkipException. If it doe

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

On 06/01/2014 16:39, Dimitar Mavrodiev wrote: Ok, better safe than sorry. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/3/index.html. Can you verify that it passes okay when you run jtreg with -vmoption:-Djava.net.preferIPv4Stack=true . I ask because I don't see a

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

On 07/01/2014 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. This looks okay to me. -Alan.

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

On 07/01/2014 12:29, Dimitar Mavrodiev wrote: Hi Alan, I've fixed that. Here's the webrev https://googledrive.com/host/0B2CI6Ih--1t5bVVwbVlBRmpVMDg/4/index.html. Thanks for the update, it seems to be okay now for IPv6 disabled case. One thing I do see though is that the test fails intermitt

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

On 10/01/2014 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/pack/coding.cpp are made consolidated and promoted to jni_util.h webrev: http://cr.openjdk.java.net/~rriggs/webrev-check-exception

hg: jdk8/tl/jaxws: 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed

Changeset: bd943bdbce05 Author:alanb Date: 2014-01-13 16:17 + URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/bd943bdbce05 8027908: serialVersionUID of javax.xml.bind.TypeConstraintException accidently changed Reviewed-by: alanb Contributed-by: iaroslav.savyts...@oracle.com

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 14/01/2014 08:40, Volker Simonis wrote: Hi, could you please review the following changes for the ppc-aix-port stage/stage-9 repositories (the changes are planned for integration into ppc-aix-port/stage-9 and subsequent backporting to ppc-aix-port/stage): I'd like to review this but I won'

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

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, I can't open the link, but yet I wouldn't mind if you folded your patch into mine. How embarrassing. Our public facing server is temporari

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 15/01/2014 06:24, David Holmes wrote: I'm not a fan of runtime checks of this kind though if it is only a very samll number of values it might be okay. Another option would be to make those classes into "templates" as done with Version.java.template and substitute the right values at buil

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 16/01/2014 09:38, Volker Simonis wrote: Hi Alan, I think sun.nio.ch.IOUtil seems even more appropriate to me for these constants. What do you think? Would it be OK for you if I initialize them right in the static initializer of IOUtil based on "os.name " or do you pref

Re: RFR: (8031737) rename jni_util.h macros for checking and returning on exceptions

On 16/01/2014 16:26, roger riggs wrote: Please review: The native macros for checking and returning when exceptions are thrown have been renamed to include the "JNU_" prefix consistent with other functions in jni_util.h. The macros have been renamed and existing uses in the jdk repository for n

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 16/01/2014 10:34, Volker Simonis wrote: : I just thought because poll is more file-descriptor oriented and not network specific. And the constants are also used for example in: src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java: src/solaris/classes/sun/nio/ch/sctp/Sctp* src/solaris/classes

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

On 17/01/2014 05:40, Tristan Yan wrote: Hi All Please review the simple code fix for JDK-8031666. http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/ This test fails in very small chance. Adding socket timeout a little bigger. Looking at JDK-8031666 then the failure seems to be with the r

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

On 17/01/2014 10:39, Tristan Yan wrote: Agree, reset timeout should be better move http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/ Thank you Tristan This looks okay but I just wonder if we also need to adjust the tolerance in checkTime. As I read it then it checks allows for +/- 50%, w

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

On 17/01/2014 11:45, Chris Hegarty wrote: On 17/01/14 11:24, Tristan Yan wrote: Shall we adjust runAfter time a little bigger also if you're doing this. Because if network is fast enough. All thing could be finished less than 3000 ms No, this is just a wait/delay time before sending the packe

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 09:59, Volker Simonis wrote: : Hi Alan, yes, that's interesting. Sounds like a very similar problem on Mac. I would suggest the following: I cut out the "Async Close AIX FIX" stuff from this change (i.e. "8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests"

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 13:45, Volker Simonis wrote: : Hi everybody, so here's the second version of this webrev: http://cr.openjdk.java.net/~simonis/webrevs/8031581_2/ This looks okay to me. The typo ("legel" -> "legal") still exists in zip_util.c and maybe that can be fixed before you push this (no

Re: RFR(L): 8031581: PPC64: Addons and fixes for AIX to pass the jdk regression tests

On 20/01/2014 16:29, Volker Simonis wrote: : @Alan: on the other hand, the bulk integration from ppc-aix-port/stage-9 to jdk9/dev is planned for next week anyway, so maybe you could wait until that happens? In that case then ignore my request, I assumed it would not be pushed to jdk9/dev until

hg: jdk8/tl/jdk: 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X

Changeset: b56ff7d30a72 Author:alanb Date: 2014-01-24 11:50 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b56ff7d30a72 8032456: vm/jni/Miscellaneous/misc001/misc00101m1/misc00101m1.html failing on OS X Reviewed-by: sla, chegar, psandoz ! src/solaris/native/common/jni_util_

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

On 31/01/2014 10:52, Chris Hegarty wrote: 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. Looks good

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

On 03/02/2014 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, hence there is no regression test.

Re: RFR: 8028725: [Parfait] warnings from b116 for jdk.src.solaris.native.java.net: JNI pending exceptions

On 04/02/2014 11:05, Michael McMahon wrote: Adding some checks for pending exceptions in the InetAddress native code. http://cr.openjdk.java.net/~michaelm/8028725/webrev.1/ This looks okay to me. Does the Windows code need the same changes? -Alan

Re: RFR: 8028725: [Parfait] warnings from b116 for jdk.src.solaris.native.java.net: JNI pending exceptions

On 04/02/2014 11:24, Alan Bateman wrote: On 04/02/2014 11:05, Michael McMahon wrote: Adding some checks for pending exceptions in the InetAddress native code. http://cr.openjdk.java.net/~michaelm/8028725/webrev.1/ This looks okay to me. Does the Windows code need the same changes? Ignore my

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

On 04/02/2014 16:12, Chris Hegarty wrote: And a link to the webrev that can people can access: http://cr.openjdk.java.net/~chegar/nativeInetCleanup/webrev/ -Chris. This is a good clean-up and looks good to me. -Alan.

8034182: Misc. warnings in java.net code

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 return value from setInet6Address_ipaddress but the return is an int rather than a pointer. In PlainDatagramSocketImpl's mcast_join_leave

Re: Adding values to enum java.net.StandardProtocolFamily

On 13/02/2014 12:54, Florian Weimer wrote: Can we add further enumeration values to java.net.StandardProtocolFamily? The spec does not say so, unlike javax.lang.model.SourceVersion, and the code in the JDK expects a binary flag, so I think the answer is "no". Does this mean the expected way

Re: Adding values to enum java.net.StandardProtocolFamily

On 13/02/2014 15:04, Florian Weimer wrote: Naming is fundamentally different. With that caveat, it would be possible to expose a socket-based interface, but application code would have to adhere to the platform naming convention. When we prototyped this in the past then we used a new Socket

Re: Remove support for old socket implementations

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 okay in principle? Could you create bug

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

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 was introduced to allow developers/customers experiment with disabling it. In JDK7 the def

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

On 22/02/2014 14:03, Bernd Eckenfels wrote: Hm, I actually like to have that JVM_ abstraction layer. Looks like it is now replaced by NET_ in some parts, do we really want to remove it in others? (the JVM_IO_ERR beeing an obvious advantage) Support for green threads went away when we moved to

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

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.openjdk.java.net/browse/JDK-8035876 This

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

On 28/02/2014 14:08, Chris Hegarty wrote: 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' ).

  1   2   3   4   5   6   7   8   9   10   >