Re: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c

Hi Chris, the fix for 8068028 was marked 9-na for some reason, as such afaik the changes were not propagated to JDK9, which changed its src tree structure at that time (i think, jdk8 were on solaris files), parfait may not have highlighted them in that context afaik the other changes in

Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c

the declaration in of plen (also scope and dad_status) as an int in enumIPv6Interfaces would appear to be done to align with its use in fscanf, even though it is a two character conversion. So would it not be more appropriate to cast it as a short when passed to addif ? the name plen would

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

, along with some stylistic and proposed re-wordings, into a webrev for your convenience: http://cr.openjdk.java.net/~chegar/8134577_comments/src/java.base/share/classes/java/net/InetAddress.java.sdiff.html -Chris. On 07/01/16 15:38, Alan Bateman wrote: On 07/01/2016 10:44, Mark Sheppard

Re: [PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

FWIW the src is restructured in JDK9, but equivalent changes exist src/java.base/unix/native/libnet/net_util_md.c src/java.base/unix/native/libnet/net_util_md.h regards Mark On 12/02/2016 11:28, Chris Hegarty wrote: On 12/02/16 11:09, Ramanand Patil wrote: Hi Sean, Since I saw the

RFR: JDK-8147862 - Null check too late in sun.net.httpserver.ServerImpl

Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8147862/webrev/ to address https://bugs.openjdk.java.net/browse/JDK-8147862 it was observed that a null check on a SocketChannel object in the Disptacher.run() method within ServerImpl, should be earlier in

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

removed references to JNDI added test for non-existent hosts file regards Mark On 06/01/2016 20:37, Alan Bateman wrote: On 06/01/2016 15:37, Mark Sheppard wrote: thanks for the feedback, Alan based on suggestions, all issues have been addressed and patch has been updated http

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

/01/2016 07:40, Alan Bateman wrote: On 31/12/2015 14:30, Mark Sheppard wrote: Hi please oblige and review the current version of the fix for https://bugs.openjdk.java.net/browse/JDK-8134577 at http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ which is based on feedback from the second

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

statements removed hosts file name in tests changed to TestHosts to avoid any potential confusion with /etc/hosts regards Mark On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

If i am right i got an thumbs up review result from Chris Hegarty for an older patch http://cr.openjdk.java.net/~dbuck/4906983.1/ (pending the outcome of the mail-exchange with Mark-Sheppard). @Chris: Am i right in my assumption? Is this still valid? The result on the pending mail-ex

Re: 8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

Hi Rob, change looks fine and handles the MS idiosyncrasies neatly change works fine ... consistent responses and failing test returns expected results regards Mark On 09/12/2015 01:44, Rob McKenna wrote: The intention of the 2nd revision of the fix is to make the undocumented

Re: Request for review & approval: 8141260: isReachable crash in windows xp

yes, the fix looks fine, and I verified the individual isReachable test on the test host where it failed. it is possible to refactor the function Java_java_net_Inet4AddressImpl_isReachable0 a little, by extracting the newly re-introduced "else" block into its own function e.g. wxp_ping4

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

, as per /etc/hosts ? do we wish that a list of ip addresses are returned, even if tests don't currently need it ? regards Mark On 22/11/2015 09:56, Alan Bateman wrote: On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please

Re: Patch for adding SO_REUSEPORT socket option

there would appear to be a link to a webrev in the JBS bug https://bugs.openjdk.java.net/browse/JDK-6432031 http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.01/ I presume

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

hosts file name in tests changed to TestHosts to avoid any potential confusion with /etc/hosts regards Mark On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ regards Mark On 25/10/2015 23:32, Mark Sheppard wrote: Hi, please oblige and review the following

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

" is more than one to avoid a possible ArrayIndexOutOfBoundsException. Looks like those methods may also be static. Artem On 10/26/2015 02:32 AM, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue ra

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

/10/2015 15:05, Alan Bateman wrote: On 25/10/2015 23:32, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi Max, thanks for the reply. I'll change the hosts file names used to correspond with an associated test dynamic update of host / ip mappings updates are accommodated as seen per the tests

RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "eliminate". As such, the interface and service descriptor

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

the following JBS item exists: https://bugs.openjdk.java.net/browse/JDK-6432031 search of windows documentation suggests that SO_REUSEPORT is still not an option man setsockopt on Solaris shows it as an option, but without precise description of semantics regards Mark On 22/10/2015 14:33,

Re: RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified

Hi Rob, looks fine ... the "him" variable in the Java_java_net_Inet4AddressImpl_isReachable0 would appear not to be used now, so could probably be removed with its call on memset ? regards Mark On 24/09/2015 15:45, Rob McKenna wrote: Please ignore the formatting errors. Thats either a

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

Hi I don't think the URL string http://server:-1/path can be considered a valid URL as the port value -1 is not legal port value. However, the URL class doesn't object and throw a MalformedURLException, which is something of an anomaly, caused by the spec allowing a port value of -1 for

Re: RFR 4906983: java.net.URL constructors throw MalformedURLException in undocumented way

I was thinking as a change for all constructors, as there are URL, which may overload authority part's structural elements such that port might be a "remote object id", or some other form of token. OK, that's fine On 13/09/2015 15:25, Chris Hegarty wrote: Is this suggested wording for the

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

quent call in the RESTARTABLE loop will return another error. On 08/09/2015 09:28, Chris Hegarty wrote: On 7 Sep 2015, at 17:41, Mark Sheppard <mark.shepp...@oracle.com> wrote: a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

ESTARTABLE loop will return another error. On 08/09/2015 09:28, Chris Hegarty wrote: On 7 Sep 2015, at 17:41, Mark Sheppard <mark.shepp...@oracle.com> wrote: a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and part of th

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

a couple of other considerations in the context of this issue perhaps? in this s is being duped onto fd, and part of the dup2 operation is the closing of fd, but what's is the expected state of file descriptor fd in the event of a dup2 failure? s is closed in any case, but what about fd,

RFR: JDK-8129507 - sun/net/www/protocol/http/B6369510.java fails intermittently

Hi Please oblige and review the change below which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8129507 This amends the url.openConnection() to take the Proxy.NO_PROXY argument, so that a direct connection is made to test http server, thus bypassing any configured and enabled

Re: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

. On 26 May 2015, at 20:21, Mark Sheppard mark.shepp...@oracle.com wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown that the Teredo

Re: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

Thanks Alan On 26/05/2015 20:34, Alan Bateman wrote: On 26/05/2015 20:21, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown

Re: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException

, Alan Bateman wrote: On 26/05/2015 20:34, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8077377/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8077377 it is possible that stray packets can be received

RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8077377/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8077377 it is possible that stray packets can be received in this MulticastSocket test, and this results in a NPE from the

RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown that the Teredo interfaces causes issue, due to its dynamic configuration, when included in the

RFR: JDK-8065078 - NetworkInterface.getNetworkInterfaces() triggers intermittent test failures

Hi please oblige and review the following small change http://cr.openjdk.java.net/~msheppar/8065078/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8065078 the getAdapters and getAdpater functions were amended in to add additional diagnostic of the error code,

RFR: JDK-8046893 - JNI exception pending in jdk/src/solaris/native/java/net: ExtendedOptionsImpl.c, PlainDatagramSocketImpl.c

Hi please review the following small change http://cr.openjdk.java.net/~msheppar/8046893/webrev/ which addresses the parfait issue in https://bugs.openjdk.java.net/browse/JDK-8046893 regards Mark

RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8046901/webrev/ which address the parfait issues in https://bugs.openjdk.java.net/browse/JDK-8046901 pertaining to uninitialized memory in src/java.base/unix/native/libnio/ch/DatagramChannelImpl.c

RFR: JDK-8068597 - Add error code to to exception condition message resulting from GetAdaptersAddresses function calls

Hi please oblige and review the following additional code to src/java.base/windows/native/libnet/NetworkInterface_winXP.c webrev: http://cr.openjdk.java.net/~msheppar/8068597/webrev/ JBS item: https://bugs.openjdk.java.net/browse/JDK-8068597 which is a temporary addition to assist in the

Re: RFR: JDK-8068597 - Add error code to to exception condition message resulting from GetAdaptersAddresses function calls

this code. -Chris. On 8 Jan 2015, at 14:16, Mark Sheppard mark.shepp...@oracle.com wrote: Hi please oblige and review the following additional code to src/java.base/windows/native/libnet/NetworkInterface_winXP.c webrev: http://cr.openjdk.java.net/~msheppar/8068597/webrev/ JBS item: https

RFR: JDK-8039595 - closed/java/net/DatagramPacket/CheckInetAddress.java fails on macosx

Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8039595/webrev/ which addresses the failures raised in https://bugs.openjdk.java.net/browse/JDK-8039595 it should also address the CheckInetAddress test failures

RFR: JDK-8066130 - com.sun.net.httpserver stop() throws NullPointerException if it is not started

Hi, Please oblige and review the minor change http://cr.openjdk.java.net/~msheppar/8066130/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8066130 a previous amendment to com.sun.net.httpserver.ServerImpl ( https://bugs.openjdk.java.net/browse/JDK-8015692) failed to

Re: URLStreamHandler.getHostAddress() performance

I think this raises a more fundamental question, as to why the URL hashCode() and equals() methods delegates to URLStreamHandler in the first place? rather than performing the processing within the URL class itself, and synchronizing appropriately within. If you call equals() and

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

name it twice ? {x- + UUID.randomUUID().toString() + -x.x- + UUID.randomUUID().toString() + -x, null}, regards Mark On 30/09/2014 16:47, Daniel Fuchs wrote: On 30/09/14 17:31, Alan Bateman wrote: On 30/09/2014 08:21, Mark Sheppard wrote: Hi Please oblige and review the following small

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

On 30/09/2014 18:53, Dmitry Samersoff wrote: Mark, It probably should be some-name.invalid IANA reserve .invalid TLD for tests like this one see: http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml -Dmitry On 2014-09-30 19:21, Mark Sheppard wrote: Hi

RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions

Message Subject: RFR: JDK-8035571 - Check jdk/src/windows/native/java/net/TwoStacksPlain* for JNI pending exceptions Date: Thu, 13 Mar 2014 20:00:30 + From: Mark Sheppard mark.shepp...@oracle.com Organization: Oracle Corporation To: OpenJDK Network Dev list net-dev

RFR: JDK-8044306 - java.net.Inet4AddressImpl.getLocalHostName() uses IPv6 rather than IPv4

Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8044306/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8044306 hints.ai_family is assigned AF_INET rather than AF_UNSPEC as the native function

Re: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

grand ... thanks Dmitry Mark On 07/08/2014 19:25, Dmitry Samersoff wrote: Mark, We can put nic.getDisplayName() under isWindows and save a bit of computer power. -Dmitry On 2014-08-07 22:15, Mark Sheppard wrote: Hi, please oblige and review the following fix http://cr.openjdk.java.net

Re: RFR: JDK-8054118 - java/net/ipv6tests/UdpTest.java failed intermittently

thanks Chris On 07/08/2014 19:20, Chris Hegarty wrote: Thanks Mark, Reviewed. -Chris. P.S. At some point in the future, we should try to create a general test utility library to retrieve suitable network interfaces for tests to use. On 7 Aug 2014, at 19:15, Mark Sheppard mark.shepp

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

Hi, please oblige and review the following diagnostic output addition to the test java/net/MulticastSocket/TestInterfaces.java http://cr.openjdk.java.net/~msheppar/8050922/webrev/ for the task https://bugs.openjdk.java.net/browse/JDK-8050922 which will assist in diagnosing an intermittent

RFR: 8041609 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions

Hi please oblige review and approve the backport to jdk8u-dev, after the review of the following change http://cr.openjdk.java.net/~msheppar/8041609/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8041609 which is a backport of

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

Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8044029/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8044029 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8025293 the changeset didn't appear to apply cleanly,

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

. Is this intentional? L555. Not directly related to your changes, but should netaddrP be freed there before returning NULL? -Chris. On 14/03/14 19:04, Mark Sheppard wrote: Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035631/webrev/ which address the issues

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

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8035631/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8035631 Summary: added CHECK_NULL_RETURN after JNI calls regards Mark

RFR: JDK-8036600 - JNI exception pending in src/jdk/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036600/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036600 summary: main changes are to check JNI return values, malloc returns and raise

RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036601 summary: NULL return value checks and JNU_ThrowOutOfMemoryError added regards Mark

Re: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

Hi Alan, thanks for the reply yes, I'll add the STS_ERROR regards Mark On 12/03/2014 16:51, Alan Bateman wrote: On 12/03/2014 16:43, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ This mostly looks good

RFR: JDK-8036607 - JNI exception pending in jdk/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c

Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036607/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8036607 Summary: Changes to src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c two additions to take

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

. -Chris. On 4 Mar 2014, at 11:06, Mark Sheppard mark.shepp...@oracle.com wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after

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

11:06, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/native/java/net

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

the selectNow() and the close() after you have joined the dispatcher thread? Since you are guaranteed that the dispatcher thread will have exited before join() returns? -Chris. On 17 Feb 2014, at 01:20, Mark Sheppard mark.shepp...@oracle.com wrote: Hi Please oblige and review the changes

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

Hi Please oblige and review the changes in the webrev http://cr.openjdk.java.net/~msheppar/8015692/jdk9/webrev/ to address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8015692 Summary: a series Junit tests which start stop instances of an

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

) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:744) regards Mark On 29/12/2013 17:05, Alan Bateman wrote: On 23/12/2013 18:21, Mark Sheppard wrote: Hi, Please oblige

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

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 an IPv6 address and no IPv4 address. The

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

Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/7102702/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-7102702 This test fails on windows, and it was found to be failing with an error WSAEFAULT (10014), when invoking a

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

, and re-execute the regression suites. regards Mark On 18/12/2013 16:05, Chris Hegarty wrote: On 18 Dec 2013, at 15:13, Alan Bateman alan.bate...@oracle.com wrote: On 18/12/2013 15:09, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net

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

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 Mark On 29/11/2013 17:17, Mark Sheppard wrote: Alan, Daniel, thanks

hg: jdk8/tl/jdk: 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java

Changeset: 39b3b0e77af5 Author:msheppar Date: 2013-12-02 14:01 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/39b3b0e77af5 8025211: Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Summary: modified test to execute in a single thread to eliminate

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

should have been this list by rights!! regards Mark Original Message Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Date: Fri, 29 Nov 2013 14:21:33 + From: Mark Sheppard mark.shepp...@oracle.com Organization

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

PM, Alan Bateman wrote: 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

hg: jdk8/tl/corba: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB

Changeset: fe781b3badd6 Author:msheppar Date: 2013-11-21 11:30 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe781b3badd6 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via

hg: jdk8/tl/jdk: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB

Changeset: d5d4b9a63174 Author:msheppar Date: 2013-11-21 11:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5d4b9a63174 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via

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

Hi Chris, yes, I concur, also regards Mark On 23/10/2013 12:09, Michael McMahon wrote: I agree. The change looks fine to me. Thanks Michael On 23/10/13 12:09, Chris Hegarty wrote: Mark, Michael, java.net.HttpCookie, rightly or wrongly, supports three different Cookie specifications.

RFR: JDK-6458027 - Disabling IPv6 on a specific network interface causes problems

Hi please oblige and review the webrev below which addresses the issue problem: https://bugs.openjdk.java.net/browse/JDK-6458027 webrev: http://cr.openjdk.java.net/~msheppar/6458027/webrev/ the core of the issue is that a windows platform may be IPv6 enabled, but an individual

RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address

) remove all exception handling code, and just declare all methods to throw Exception. The jtreg harness will show the test as failed if an unhandled exception is thrown. -Chris. On 04/09/2013 08:59, Mark Sheppard wrote: Hi based on feedback for initial fix, an amended webrev has been

RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address

Hi based on feedback for initial fix, an amended webrev has been created. So, please oblige and review the fix below to address the issue in JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address webrev: http://cr.openjdk.java.net/~msheppar/8021372/webrev.01/

RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address

Hi please oblige and review the fix below to address the issue in JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address http://cr.openjdk.java.net/~msheppar/8021372/webrev/ the handling of the Ipv6IfIndex was suspect when setting the interface index and when

Re: RFR:JDK-8021372 NetworkInterface.getNetworkInterfaces() returns duplicate hardware address

it. It might make sense to explicitly check passed index for 0 above loop. -Dmitry On 2013-09-03 13:23, Mark Sheppard wrote: Hi please oblige and review the fix below to address the issue in JDK-8021372: NetworkInterface.getNetworkInterfaces() returns duplicate hardware address http

RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally

Hi please oblige and review the fix below to address the issue in JDK-8023326 which makes the test more robust to certain exceptions thrown. http://cr.openjdk.java.net/~msheppar/8023326/webrev/ regards Mark --- old/test/java/net/CookieHandler/LocalHostCookie.javaWed Aug 21 12:23:21

RFR: JDK-8007373 Inet6Address serialization incompatibility

Hi, could you oblige and review the webrev below as a fix for the issue raised in JDK8007373, Inet6Address serialization incompatibility http://cr.openjdk.java.net/~msheppar/8007373/webrev.00/ Description: We seem to have changed the serialization of Inet6Address in jdk8 compared with

RFR: (JDK-8005406) HTTP server implementation should use Base64 API

java.util.Base64. This makes changes to the BasicAuthenticator class to use java.util.Base64.Decoder, and removes a package private Base64 class. webrev located at http://cr.openjdk.java.net/~chegar/8005406 regards Mark Sheppard

<    1   2