Withdrawn: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

On Mon, 11 Jan 2021 17:24:23 GMT, Volker Simonis wrote: > JDK-8237578 exposes some SocketExceptions directly which were previously > wrapped inside an SSLException. The change updated one test to take this new > behaviour into account (i.e. TrustTrustedCert.java) but apparently missed

RFR: 8259572: [test] Fix SSL tests after JDK-8237578 to properly handle SocketExceptions

JDK-8237578 exposes some SocketExceptions directly which were previously wrapped inside an SSLException. The change updated one test to take this new behaviour into account (i.e. TrustTrustedCert.java) but apparently missed other tests. The fix for the other tests is similar like the fix for Tr

Re: Enable system proxies by default on Linux?

My colleague Arno did some work on this for Java 9/10 (see https://bugs.openjdk.java.net/browse/JDK-8170868) Added him on CC as well as I'm not sure he's following net-dev. Daniel Fuchs schrieb am Mi., 25. Sep. 2019, 12:56: > Hi, > > On 25/09/2019 08:20, Alan Bateman wrote: > > On 24/09/2019 23

Re: 8207404: MulticastSocket tests failing on Aix

Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groe...@uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Har

Re: 8207404: MulticastSocket tests failing on Aix

I think the difference is in setMulticastInterface() in PlainDatagramSocketImpl.c #ifdef __linux__ mcast_set_if_by_if_v4(env, this, fd, value); if (ipv6_available()) { if ((*env)->ExceptionCheck(env)){ (*env)->ExceptionClear(env); }

Re: [XS] RFR: 8209994: windows: Java_java_net_NetworkInterface_getAll misses releasing interface-list

(missing > free_netif calls in case of "early" returns ). > I adjusted this as well in the second webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8209994.1/ > > > Best regards , Matthias > > > > -Original M

Re: [XS] RFR: 8209994: windows: Java_java_net_NetworkInterface_getAll misses releasing interface-list

Hi Matthias, the change looks good but I think you should also initialize 'ifList' in 'Java_java_net_NetworkInterface_getAll()' with NULL otherwise its value is undefined and if 'enumInterfaces()' returns with an error without assigning 'ifList' you may end up calling 'free_netif()' with an undefi

Re: RFR(XS): 8188855: Fix VS10 build after "8187658: Bigger buffer for GetAdaptersAddresses"

Looks good! Thanks, Volker On Fri, Oct 6, 2017 at 8:48 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get reviews for this tiny change? > http://cr.openjdk.java.net/~goetz/wr17/8188855-winBuild/webrev/ > > Best regards, > Goetz.

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Hi Chris, this change is fine for me now and I think Arno addressed all of your concerns. Is it OK for you if I push this to 9 and add you as one of the reviewers? Thank you and best regards, Volker On Wed, Jan 11, 2017 at 3:21 PM, Zeller, Arno wrote: > Hi Chris, > > I have addressed your comm

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

On Fri, Dec 23, 2016 at 2:57 PM, Chris Hegarty wrote: > Arno, > >> On 22 Dec 2016, at 16:44, Zeller, Arno wrote: >> >> Hi Vyom, >> >> thanks for the comments – now I understand the problem. I reworked all three >> platforms to check for exceptions and NULL if needed. >> Regarding the JNIReleaseS

Re: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

On Thu, Dec 22, 2016 at 9:41 PM, Thomas Stüfe wrote: > Hi Arno, > > good job, this is a nice addition! > > Some remarks/questions (not a full review): > > 1) The naming of the unix...DefaultProxySelector.c is confusing. Could we > rename it to gnome/../DefaultProxySelector? > I don't think that w

Re: RFR: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome

Hi Arno, you change looks good. Thanks for addressing this long standing issue! Please find some minor comments below: - make/lib/NetworkingLibraries.gmk 28 ifeq ($(OPENJDK_TARGET_OS), macosx) 29LIBNET_EXCLUDE_FILES := DefaultProxySelector.c 30 endif Have you tried to use LIBNET_EXCLU

Re: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi Christoph, this change looks reasonable but I wonder if this requires one of these dubious CCC requests/approvals? Maybe one of the process experts can answer :) Regards, Volker On Wed, Dec 7, 2016 at 9:38 AM, Langer, Christoph wrote: > Hi, > > > > please review this small fix. > > > > Bug:

Re: RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c

Thanks a lot Chris for the ultra-fast review! Regards, Volker On Fri, Oct 21, 2016 at 2:50 PM, Chris Hegarty wrote: > On 21/10/16 13:49, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for the following trivial fix: >> >> http://cr.openjdk

RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c

Hi, can I please get a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8168471/ https://bugs.openjdk.java.net/browse/JDK-8168471 Change "8168405: Pending exceptions in java.base/windows/native" introduced the following non ANSI C compatible code for declari

Re: RFR (XXS): 8162811: use correct IPv6 multicast socket options for AIX in PlainDatagramSocketImpl.c

Hi Christoph, in general your change looks good, because the setsockopt man-page on AIX only defines IPV6_JOIN_GROUP/IPV6_LEAVE_GROUP but not IPV6_ADD_MEMBERSHIP/IPV6_DROP_MEMBERSHIP. On the other hand I was surprised that the original code compiled before. Looking into the AIX headers, I found:

Re: Patch for adding SO_REUSEPORT socket option

etImpl.java and > java/net/TwoStacksPlainSocketImpl.java also need tweaking on that message. > > Thanks, > Sean. > > > On 17/02/16 11:43, Chris Hegarty wrote: >> >> >>> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Lu, >>

Re: Patch for adding SO_REUSEPORT socket option

Hi Alan, I'm just running a quick test build on AIX to see if everything is still working. I'll let you know once it completes (latest today evening). Thanks, Volker On Tue, Feb 16, 2016 at 11:18 PM, Alan Bateman wrote: > > > On 16/02/2016 18:03, Lu, Yingqi wrote: >> >> Hi Alan, >> >> I am won

RFR(XS): 8146482: [TESTBUG] java/net/SocketOption/OptionTest should only use multicast capable interfaces for multicast tests

Hi, can somebody please review this small test fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8146482/ https://bugs.openjdk.java.net/browse/JDK-8146482 The java/net/SocketOption/OptionTest test chooses the first network interface returned by NetworkInterface.getNetworkInterfaces() for doi

Re: Patch for adding SO_REUSEPORT socket option

: > > > On 04/01/2016 19:24, Volker Simonis wrote: >> >> On Mon, Jan 4, 2016 at 8:02 PM, Lu, Yingqi wrote: >>> >>> : >>> >>> 2. Regarding to the code snippet in net_util_md.c, the reason I check for >>> ENOPROTOOPT is to enable SO_REU

Re: Patch for adding SO_REUSEPORT socket option

On Mon, Jan 4, 2016 at 8:24 PM, Alan Bateman wrote: > > > On 04/01/2016 18:43, Volker Simonis wrote: >> >> : >> Alan, what do you mean by "unknown" platform? Currently, as far as I >> know, 0x0200 is used by AIX and MacOS X. Do you suggest to name th

Re: Patch for adding SO_REUSEPORT socket option

;s opinion. > Again, really appreciate the quick responses and helpful feedback from both > of you :-) > > Thanks, > Lucy > > -Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > Sent: Monday, January 04, 2016 10:43 AM > To: Alan Bateman

Re: Patch for adding SO_REUSEPORT socket option

Hi Lucy, Alan, I'm back from vacation so here we go :) On Fri, Jan 1, 2016 at 12:18 PM, Alan Bateman wrote: > > On 21/12/2015 17:53, Lu, Yingqi wrote: >> >> Hi All, >> >> Sorry for the late reply. Here is the link to the most recent reversion of >> the patch (version #6). >> http://cr.openjdk.

Re: Patch for adding SO_REUSEPORT socket option

lock. I think we simply shouldn't implicitly set SO_REUSEPORT. We should leave that up to the user, if he thinks it is necessary. Or am I missing something here? > > Thanks, > Lucy > > -Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.com] > S

Re: Patch for adding SO_REUSEPORT socket option

right of all the files you've touched has to be updated to 2015 (or 2016 :) Regards, Volker On Wed, Dec 2, 2015 at 6:08 PM, Lu, Yingqi wrote: > Hi All, > > > > A quick check here. Does anyone get a chance to try the most recent patch? > Any feedback and comments? > >

Re: Patch for adding SO_REUSEPORT socket option

n old kernel > which does not have SO_REUSEPORT enabled. In this case, it should not set > the flag. > > Let me double check. I will get back to you as soon as I can. > > Thanks, > Lucy > > -----Original Message- > From: Volker Simonis [mailto:volker.simo...@gmail.

Re: Patch for adding SO_REUSEPORT socket option

t-dev-boun...@openjdk.java.net] On Behalf Of Michael > McMahon > Sent: Monday, November 23, 2015 2:54 AM > To: Volker Simonis ; Alan Bateman > > Cc: Kharbas, Kishor ; net-dev@openjdk.java.net > Subject: Re: Patch for adding SO_REUSEPORT socket option > > I agree we should

Re: Patch for adding SO_REUSEPORT socket option

e OSes so that I might not be able to >> test them. Can any of you please help with the testing? >> >> Alan, I will add the isReusePortSupported method in the Net.c and only add >> SO_REUSEPORT into the options set only when it is supported. >> >> Thank you, >

Re: Patch for adding SO_REUSEPORT socket option

x27;ve mentioned is in http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/unix/native/libnet/net_util_md.c#l1487 > For reference, SO_REUSEPORT on Linux is documented here > http://man7.org/linux/man-pages/man7/socket.7.html > Thanks for providing the link. > - Michael > > >

Re: Patch for adding SO_REUSEPORT socket option

Hi Lucy, in general I support the addition of SO_REUSEPORT to the set of standard socket options. However for me the problem is not that this new option is not supported on all platforms, but instead that it has such different semantics on different platforms. If you look at the code, you'll see t

Re: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()

ebrevs/8060470.v2/ Can I please also get a review with regards to the content of this change (as opposed to its form:) Thank you and best regards, Volker On Mon, Oct 27, 2014 at 7:27 PM, Alan Bateman wrote: > On 27/10/2014 17:45, Volker Simonis wrote: >> >> : >> Well, the p

Re: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()

tic-variables-in-c-and-c). I could of course use a second static varibale to do the initialization only once, but I think that's not worth it. Thanks, Volker > Sincerely yours, > Ivan > > > On 24.10.2014 18:47, Volker Simonis wrote: >> >> Hi, >> >>

Re: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()

Hi, could somebody please have a quick look at this change. It's really not that complicated as it looks like from the comments - I just didn't manage to write it up in a more concise way :) Thanks, Volker On Thu, Oct 16, 2014 at 4:39 PM, Volker Simonis wrote: > Hi, > > co

RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()

Hi, could you please hava a look at the following change: http://cr.openjdk.java.net/~simonis/webrevs/8060470.v1 https://bugs.openjdk.java.net/browse/JDK-8060470 It's probably easier to read the following in the webrev, but I copy it below for discussion. Regards, Volker So here comes the firs

Re: Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName()

; Before >> we change it, I'd like to check back through the history to see why >> exactly >> it was done and will report back. >> >> Thanks, >> Michael >> >> On 08/10/14 17:59, Volker Simonis wrote: >>> >>> Hi, >>> >>

Eliminate differences between Inet6AddressImpl_getLocalHostName() and Inet4AddressImpl_getLocalHostName()

Hi, I wonder why the implementations of Inet6AddressImpl_ getLocalHostName() and Inet4AddressImpl_getLocalHostName() are different . It seems to me that this is simply copy/paste error since the very first 1.4 version. Here's what we currently have: Inet4AddressImpl_getLocalHostName() if (gethos

Re: RFR 8043954: Fix behavior difference of connect() for AIX

Hi Jonathan, I just wanted to let you know that I've build your changes on AIX 5..3 and 7.1. I've also run the jdk regression tests without specific issues. So thumbs up from me! Regards, Volker On Fri, Jun 6, 2014 at 12:03 PM, Jonathan Lu wrote: > Hi Alan, > > On Fri, Jun 6, 2014 at 1:53 AM,

Re: RFR 8043954: Fix behavior difference of connect() for AIX

Hi Jonathan, thanks for fixing this! I've looked at the change and it looks good to me (but I'm not a reviewer). The only minor flaw I found is that you declare the helper variable 'int rc = -1' but never assign it. Instead you could just return '-1' directly where you currently return 'rc' and re

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

Hi Alan, Chris, thanks for the review. I've just pushed the change with the additions proposed by you (I also removed the similar blocks/comments in PlainSocketImpl.c). Regards, Volker On Fri, Feb 28, 2014 at 3:14 PM, Alan Bateman wrote: > On 28/02/2014 14:08, Chris Hegarty wrote: >> >> Volker

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

Hi, could you please review the following clean-up change (for a better formatted description please see the webrev): http://cr.openjdk.java.net/~simonis/webrevs/8035949/ https://bugs.openjdk.java.net/browse/JDK-8035949 This change removes some unused code and macros from src/solaris/native/java

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

Hi, first of all I know that I have to blame myself for not subscribing to the net-dev list (I thought I was but there are much too many lists to really keep track:) Nevertheless I would like to kindly ask everybody who changes AIX related stuff (as it was done in '8034174: Remove use of JVM_* fu

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

On Fri, Jan 17, 2014 at 10:15 PM, Volker Simonis wrote: > On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman > wrote: >> On 14/01/2014 08:40, Volker Simonis wrote: >>> >>> Hi, >>> >>> could you please review the following changes for the ppc-aix-port

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

On Mon, Jan 20, 2014 at 12:41 PM, Alan Bateman wrote: > 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: >> >&

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

On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > 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 >&

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

On Mon, Jan 20, 2014 at 4:24 PM, Alan Bateman wrote: > 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/ > &g

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

re/transport/socket/socketTransport.c > No comments. > > > src/share/classes/sun/tools/attach/META-INF/services/com.sun.tools.attach.spi.AttachProvider > No comments. > > > Thanks, > /Staffan > > > > On 14 jan 2014, at 09:40, Volker Simonis wrote: >

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

On Wed, Jan 15, 2014 at 6:27 PM, Volker Simonis wrote: > On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis > wrote: >> Hi Staffan, >> >> thanks for the review. Please find my comments inline: >> >> On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen &

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

On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > 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

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

On Wed, Jan 15, 2014 at 5:34 PM, Volker Simonis wrote: > Hi Staffan, > > thanks for the review. Please find my comments inline: > > On Wed, Jan 15, 2014 at 9:57 AM, Staffan Larsen > wrote: >> >> Volker, >> >> I’ve look at the following fi

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

On Thu, Jan 16, 2014 at 11:05 AM, Alan Bateman wrote: > 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 initi

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

think about assigning the concrete values depending on 'os.name' in the static initializers of the corresponding classes? I think that shouldn't introduce too much overhead and I could get rid of all the ugly conversion code. Regards, Volker > David > > > On 14/01/2014

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

On Wed, Jan 15, 2014 at 12:05 PM, Volker Simonis wrote: > > > > On Wed, Jan 15, 2014 at 10:03 AM, Alan Bateman wrote: > >> 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

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

Hi Alan, On Tue, Jan 14, 2014 at 10:19 AM, Alan Bateman wrote: > 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 in

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

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): http://cr.openjdk.java.net/~simonis/webrevs/8031581/ I've build and smoke tested

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

will now call 'aix_close_init()' as suggested by Alan. The changes to src/solaris/native/com/sun/ management/UnixOperatingSystem_md.c are now in src/solaris/native/sun/management/OperatingSystemImpl.c because that file was moved by an upstream change. On Wed, Nov 20, 2013 at 7:26 PM, Volk

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

tps://bugs.openjdk.java.net/browse/JDK-8024900) This change only contains the additional make changes which became necessary after I started to move AIX-specific files into their own jdk/src/aix/ directory. Everything else is already in place. I'll prepare and test a finaly webrev with all t

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

again, Volker > > Thanks, > > Artem > > On 11/20/2013 10:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on AIX >> <https://bugs.openjdk.jav

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

e AWT/2D guys. As far as I understood, you've now reviewed the 'core-lib'/'net' parts right? That would mean that I'll still need a review from the AWT/2D and the Security group - any volunteers:). Once again thanks a lot for your help, Volker On Fri, Nov 22, 2

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

6997010 > > Thanks, > Sean > > On 11/20/2013 01:26 PM, Volker Simonis wrote: > >> Hi, >> >> this is the second review round for "8024854: Basic changes and files to >> build the class library on >> AIX<https://bugs.openjdk.java.net/browse/

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

/sun/management/OperatingSystemImpl.c. Fortunately, my changes to UnixOperatingSystem_md.c described in the webrev apply cleanly to the new file (I've tested this locally). I'll update the webrev accordingly once I've collected some more feedback. Thank you and best regards, Volker On Wed, Nov 20, 2

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

Hi Alan, thanks a lot for the fast review and your valuable comments. Please find my answers inline: On Thu, Nov 21, 2013 at 1:01 PM, Alan Bateman wrote: > On 20/11/2013 18:26, Volker Simonis wrote: > > Hi, > > this is the second review round for "8024854: Basic changes

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

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've tried to address all the comments and suggestio