From chris.hegarty at oracle.com Tue Jan 3 13:59:29 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Jan 2017 13:59:29 +0000 Subject: RFR: 8170544: Fix code scan findings in libnet In-Reply-To: References: <583F04DE.9060706@oracle.com> <703e4795f5bd4ba1afd2af60c090f409@DEWDFE13DE03.global.corp.sap> <4e7c5f041dda445abb2869c3da5def4b@DEROTE13DE08.global.corp.sap> Message-ID: <48B4053C-51F3-4BB3-A0E4-0AF07737DA0D@oracle.com> > On 29 Dec 2016, at 13:20, Langer, Christoph wrote: > > Hi Goetz, > > thanks for reviewing this. > > I have addressed your comments in a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8170544.1/ This mainly looks fine. Just a few comments: 1) NetworkInterface.c I?m not sure that the close is really necessary, since a JNI pending exception can only be thrown is sock is less than 0. I think just removing the ' && (*env)->ExceptionOccurred(env)? from the original if statement should be sufficient, no? 2) net_util.c getInet6Address_scopeid_set should CHECK_NULL_RETURN(holder, JNI_FALSE)? getInet6Address_scopeid now returns an unsigned in, why CHECK_NULL_RETURN(holder, -1)? Some of this, existing, code seems a little dubious. -Chris. From chris.hegarty at oracle.com Tue Jan 3 14:04:06 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Jan 2017 14:04:06 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> Message-ID: Arno, > On 27 Dec 2016, at 11:44, Zeller, Arno wrote: > > Hi Chris, > > Thanks for having a look at my change: > >> 1) It seems awful to have to deal with LinkedList in native code. How >> about returning an array from native, and then converting that into >> whatever list type is appropriate at the Java level. > With the current implementation on Mac I do not know upfront how many items the list will contain and therefore I preferred to use the LinkedList from native code. > I can of course change the implementation on Mac to first generate a fully resolved native list and then I can use NewObjectArray to generate an Array of Proxy objects to return. This will avoid calling to java to add an element to the list. Do you think this will be better? Yes. Thanks. >> 2) I would prefer the use of List.of(...), and list.of() for empty, since >> these are immutable and efficient list implementations. > I thought about that but I tried to not return an immutable List because the Javadoc of Proxy.select does not state anything about the returned List (if it is immutable or not) and I feared to break compatibility by returning an immutable List. > If you think this is no problem I will of course prefer to always return the same immutable NO_PROXY list object. I would prefer an immutable list. Maybe we file, a separate, issue to amend the spec to say "returns an immutable list ??. >> 3) Is the comment ?Inspired ...? necessary / appropriate? > I will change it to the comment proposed by Volker. Ok. >> 4) Can some of the native initialization code be moved to a platform >> independent location, to remove duplication? > Would it be ok if I move the definition of the static variables and the implementation of 'static int initJavaClass(...)' to a header file in the shared branch. I.e. src/java.base/shared/native/libnet/DefaultProxySelector.h and include this in the MacOSX, Windows and the Unix implementations? Yes. >> 5) The new file has a shared copyright header. I see similar SAP >> headers in a few files, but none shared with the Oracle header. >> How did you arrive at this format? > The format was suggested to me by Volker :-) Ok. -Chris. From chris.hegarty at oracle.com Tue Jan 3 14:09:55 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 Jan 2017 14:09:55 +0000 Subject: RFR[9] JDK-8170641: sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails with timeout In-Reply-To: <93ac0d40-022b-2aee-f922-68a269a0ccaa@oracle.com> References: <93ac0d40-022b-2aee-f922-68a269a0ccaa@oracle.com> Message-ID: On 27 Dec 2016, at 06:24, John Jiang wrote: > > Hi, > sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh failed with timeout. > The client side could hang if the server goes to timeout before getting the client request, and the proxy also could be blocked. > > This patch sets timeout for the server and the client and catches SocketTimeoutException to ignore the . And it removes the usage on shell script. > The patch also modifies test sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh as this test has the similar code pattern and issue. > > Webrev: http://cr.openjdk.java.net/~jjiang/8170641/webrev.00/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8170641 Looks good John. Thanks, -Chris. From claes.redestad at oracle.com Tue Jan 3 14:46:53 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 3 Jan 2017 15:46:53 +0100 Subject: RFR: 8170785: Excessive allocation in ParseUtil.encodePath Message-ID: <7ae2434a-da5b-ec52-c4cc-0dc8631c6eb1@oracle.com> Hi, some users reports high allocation rates in ParseUtil.encodePath, regardless of whether paths actually need to be encoded or not. Since this is a commonly used utility it makes sense. Webrev: http://cr.openjdk.java.net/~redestad/8170785/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8170785 This patch provides a semantically neutral fast-path for cases when the path does not need to be encoded (up to 5x speedup), reduces allocation when the string has a prefix that does not need to be encoded (1-2x speedup) and no regression when using a separator that's not '/' or the first char needs encoding. Interpreted performance is not affected much either: small positive when no encoding is needed, neutral or negligible regression otherwise. Thanks! /Claes From christoph.langer at sap.com Mon Jan 9 05:56:30 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Jan 2017 05:56:30 +0000 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Message-ID: Ping: Please review this backport to JDK8. From: Langer, Christoph Sent: Donnerstag, 29. Dezember 2016 10:37 To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Hi, please review (and eventually approve) the change for downporting 8075484. Webrev for 8u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd JDK9 Review Thread(s): http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html We had customer reports who ran into that issue with Java 8. So this should be downported. The problem is, that the fix does not apply to Solaris as Solaris needs some calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still supported (though deprecated). But I think it is still worthwile to bring this down for the other platforms which I'm proposing with my changeset. So I extracted the new code manually from the JDK9 changeset and made it fit into JDK8 coding. Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vyom.tewari at oracle.com Tue Jan 10 07:58:12 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Tue, 10 Jan 2017 13:28:12 +0530 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: References: Message-ID: <5b61e151-abae-7dbe-8994-8485a900fa2f@oracle.com> Hi Christoph, Code change looks good to me, but i am not an official reviewer. Thanks, Vyom On Monday 09 January 2017 11:26 AM, Langer, Christoph wrote: > > Ping: Please review this backport to JDK8. > > *From:*Langer, Christoph > *Sent:* Donnerstag, 29. Dezember 2016 10:37 > *To:* net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > *Subject:* [8u-dev]: Request for Review and Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > Hi, > > please review (and eventually approve) the change for downporting 8075484. > > Webrev for 8u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > > > JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > > JDK9 Review Thread(s): > > http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html > > http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html > > We had customer reports who ran into that issue with Java 8. So this > should be downported. > > The problem is, that the fix does not apply to Solaris as Solaris > needs some calls into hotspot. This is because in JDK 8 the flag for > interruptible IO is still supported (though deprecated). But I think > it is still worthwile to bring this down for the other platforms which > I?m proposing with my changeset. So I extracted the new code manually > from the JDK9 changeset and made it fit into JDK8 coding. > > Thanks & Best regards > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Jan 11 10:47:15 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 11 Jan 2017 10:47:15 +0000 Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: References: Message-ID: <567ED767-D294-444E-8154-7873F3D9BE96@oracle.com> Hi Christoph, > On 9 Jan 2017, at 05:56, Langer, Christoph wrote: > > Ping: Please review this backport to JDK8. > > From: Langer, Christoph > Sent: Donnerstag, 29. Dezember 2016 10:37 > To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: [8u-dev]: Request for Review and Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set > > Hi, > > please review (and eventually approve) the change for downporting 8075484. > > Webrev for 8u-dev: http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ The changes look ok to me. > Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > JDK9 Review Thread(s): > http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html > http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010201.html > > We had customer reports who ran into that issue with Java 8. So this should be downported. > > The problem is, that the fix does not apply to Solaris as Solaris needs some calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still supported (though deprecated). But I think it is still worthwile to bring this down for the other platforms which I?m proposing with my changeset. So I extracted the new code manually from the JDK9 changeset and made it fit into JDK8 coding. Ok, I see the complication. On Solaris these calls still go through the VM to support Interruptible IO ( through the JVM_XXX interface). Thankfully, this is no longer the case in 9. -Chris. From christoph.langer at sap.com Wed Jan 11 13:28:17 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Jan 2017 13:28:17 +0000 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set Message-ID: Hi, please approve this downport. Thanks, Chris, for the Review. Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 11. Januar 2017 11:47 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net > Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > Hi Christoph, > > > On 9 Jan 2017, at 05:56, Langer, Christoph > wrote: > > > > Ping: Please review this backport to JDK8. > > > > From: Langer, Christoph > > Sent: Donnerstag, 29. Dezember 2016 10:37 > > To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > > Subject: [8u-dev]: Request for Review and Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > > > Hi, > > > > please review (and eventually approve) the change for downporting 8075484. > > > > Webrev for 8u-dev: > http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > > The changes look ok to me. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > > JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > > JDK9 Review Thread(s): > > http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html > > http://mail.openjdk.java.net/pipermail/net-dev/2016- > September/010201.html > > > > We had customer reports who ran into that issue with Java 8. So this should > be downported. > > > > The problem is, that the fix does not apply to Solaris as Solaris needs some > calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still > supported (though deprecated). But I think it is still worthwile to bring this > down for the other platforms which I?m proposing with my changeset. So I > extracted the new code manually from the JDK9 changeset and made it fit into > JDK8 coding. > > Ok, I see the complication. On Solaris these calls still go through > the VM to support Interruptible IO ( through the JVM_XXX interface). > Thankfully, this is no longer the case in 9. > > -Chris. From david.buck at oracle.com Wed Jan 11 13:50:37 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 11 Jan 2017 22:50:37 +0900 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: References: Message-ID: <5876382D.4060701@oracle.com> approved for push to 8u-dev once appropriate noreg label has been added to the bug report [ noreg bug labels ] http://openjdk.java.net/guide/changePlanning.html#noreg Cheers, -Buck On 2017/01/11 22:28, Langer, Christoph wrote: > Hi, > > please approve this downport. > > Thanks, Chris, for the Review. > > Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Mittwoch, 11. Januar 2017 11:47 >> To: Langer, Christoph >> Cc: net-dev at openjdk.java.net >> Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: >> SocketInputStream.socketRead0 can hang even with soTimeout set >> >> Hi Christoph, >> >>> On 9 Jan 2017, at 05:56, Langer, Christoph >> wrote: >>> >>> Ping: Please review this backport to JDK8. >>> >>> From: Langer, Christoph >>> Sent: Donnerstag, 29. Dezember 2016 10:37 >>> To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net >>> Subject: [8u-dev]: Request for Review and Approval: 8075484: >> SocketInputStream.socketRead0 can hang even with soTimeout set >>> >>> Hi, >>> >>> please review (and eventually approve) the change for downporting 8075484. >>> >>> Webrev for 8u-dev: >> http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ >> >> The changes look ok to me. >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 >>> JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd >>> JDK9 Review Thread(s): >>> http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010171.html >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- >> September/010201.html >>> >>> We had customer reports who ran into that issue with Java 8. So this should >> be downported. >>> >>> The problem is, that the fix does not apply to Solaris as Solaris needs some >> calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still >> supported (though deprecated). But I think it is still worthwile to bring this >> down for the other platforms which I?m proposing with my changeset. So I >> extracted the new code manually from the JDK9 changeset and made it fit into >> JDK8 coding. >> >> Ok, I see the complication. On Solaris these calls still go through >> the VM to support Interruptible IO ( through the JVM_XXX interface). >> Thankfully, this is no longer the case in 9. >> >> -Chris. > From arno.zeller at sap.com Wed Jan 11 14:21:14 2017 From: arno.zeller at sap.com (Zeller, Arno) Date: Wed, 11 Jan 2017 14:21:14 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> Message-ID: Hi Chris, I have addressed your comments in a new webrev. Can you please have a look at this one? http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ I created src/java.base/share/native/libnet/proxy_util.c/h and these files contain now the common used native parts. And I rewrote the code to return an array of Proxy objects from native code - so I do no longer call back to Java to add an object to the list. Best regards, Arno >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Dienstag, 3. Januar 2017 15:04 >To: Zeller, Arno >Cc: net-dev at openjdk.java.net >Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >on Windows, MacOS and Gnome > >Arno, > >> On 27 Dec 2016, at 11:44, Zeller, Arno wrote: >> >> Hi Chris, >> >> Thanks for having a look at my change: >> >>> 1) It seems awful to have to deal with LinkedList in native code. How >>> about returning an array from native, and then converting that into >>> whatever list type is appropriate at the Java level. >> With the current implementation on Mac I do not know upfront how many >items the list will contain and therefore I preferred to use the LinkedList from >native code. >> I can of course change the implementation on Mac to first generate a fully >resolved native list and then I can use NewObjectArray to generate an Array >of Proxy objects to return. This will avoid calling to java to add an element to >the list. Do you think this will be better? > >Yes. Thanks. > >>> 2) I would prefer the use of List.of(...), and list.of() for empty, since >>> these are immutable and efficient list implementations. >> I thought about that but I tried to not return an immutable List because the >Javadoc of Proxy.select does not state anything about the returned List (if it is >immutable or not) and I feared to break compatibility by returning an >immutable List. >> If you think this is no problem I will of course prefer to always return the >same immutable NO_PROXY list object. > >I would prefer an immutable list. Maybe we file, a separate, issue to amend >the spec to say "returns an immutable list ??. > >>> 3) Is the comment ?Inspired ...? necessary / appropriate? >> I will change it to the comment proposed by Volker. > >Ok. > >>> 4) Can some of the native initialization code be moved to a platform >>> independent location, to remove duplication? >> Would it be ok if I move the definition of the static variables and the >implementation of 'static int initJavaClass(...)' to a header file in the shared >branch. I.e. src/java.base/shared/native/libnet/DefaultProxySelector.h and >include this in the MacOSX, Windows and the Unix implementations? > >Yes. > >>> 5) The new file has a shared copyright header. I see similar SAP >>> headers in a few files, but none shared with the Oracle header. >>> How did you arrive at this format? >> The format was suggested to me by Volker :-) > >Ok. > >-Chris. From christoph.langer at sap.com Wed Jan 11 14:34:39 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Jan 2017 14:34:39 +0000 Subject: [8u-dev]: Request for Approval: 8075484: SocketInputStream.socketRead0 can hang even with soTimeout set In-Reply-To: <5876382D.4060701@oracle.com> References: <5876382D.4060701@oracle.com> Message-ID: <29a409b6164e423e91de06596b7734cc@DEWDFE13DE03.global.corp.sap> Thanks Buck. I added the label and pushed: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/c43400eba8a3 I also added #include to net_util_md.c which I forgot in my webrev. Best regards Christoph > -----Original Message----- > From: David Buck [mailto:david.buck at oracle.com] > Sent: Mittwoch, 11. Januar 2017 14:51 > To: Langer, Christoph ; jdk8u- > dev at openjdk.java.net > Cc: net-dev at openjdk.java.net > Subject: Re: [8u-dev]: Request for Approval: 8075484: > SocketInputStream.socketRead0 can hang even with soTimeout set > > approved for push to 8u-dev once appropriate noreg label has been added > to the bug report > > [ noreg bug labels ] > http://openjdk.java.net/guide/changePlanning.html#noreg > > Cheers, > -Buck > > On 2017/01/11 22:28, Langer, Christoph wrote: > > Hi, > > > > please approve this downport. > > > > Thanks, Chris, for the Review. > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Mittwoch, 11. Januar 2017 11:47 > >> To: Langer, Christoph > >> Cc: net-dev at openjdk.java.net > >> Subject: Re: [8u-dev]: Request for Review and Approval: 8075484: > >> SocketInputStream.socketRead0 can hang even with soTimeout set > >> > >> Hi Christoph, > >> > >>> On 9 Jan 2017, at 05:56, Langer, Christoph > >> wrote: > >>> > >>> Ping: Please review this backport to JDK8. > >>> > >>> From: Langer, Christoph > >>> Sent: Donnerstag, 29. Dezember 2016 10:37 > >>> To: net-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > >>> Subject: [8u-dev]: Request for Review and Approval: 8075484: > >> SocketInputStream.socketRead0 can hang even with soTimeout set > >>> > >>> Hi, > >>> > >>> please review (and eventually approve) the change for downporting > 8075484. > >>> > >>> Webrev for 8u-dev: > >> http://cr.openjdk.java.net/~clanger/webrevs/8075484.8udev/ > >> > >> The changes look ok to me. > >> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8075484 > >>> JDK9 Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af17b6bc08dd > >>> JDK9 Review Thread(s): > >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- > August/010171.html > >>> http://mail.openjdk.java.net/pipermail/net-dev/2016- > >> September/010201.html > >>> > >>> We had customer reports who ran into that issue with Java 8. So this should > >> be downported. > >>> > >>> The problem is, that the fix does not apply to Solaris as Solaris needs some > >> calls into hotspot. This is because in JDK 8 the flag for interruptible IO is still > >> supported (though deprecated). But I think it is still worthwile to bring this > >> down for the other platforms which I?m proposing with my changeset. So I > >> extracted the new code manually from the JDK9 changeset and made it fit > into > >> JDK8 coding. > >> > >> Ok, I see the complication. On Solaris these calls still go through > >> the VM to support Interruptible IO ( through the JVM_XXX interface). > >> Thankfully, this is no longer the case in 9. > >> > >> -Chris. > > From christoph.langer at sap.com Wed Jan 11 15:50:03 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Jan 2017 15:50:03 +0000 Subject: RFR: 8170544: Fix code scan findings in libnet In-Reply-To: <48B4053C-51F3-4BB3-A0E4-0AF07737DA0D@oracle.com> References: <583F04DE.9060706@oracle.com> <703e4795f5bd4ba1afd2af60c090f409@DEWDFE13DE03.global.corp.sap> <4e7c5f041dda445abb2869c3da5def4b@DEROTE13DE08.global.corp.sap> <48B4053C-51F3-4BB3-A0E4-0AF07737DA0D@oracle.com> Message-ID: <0c5d9c9f2db14eba976c51f585e57147@DEWDFE13DE03.global.corp.sap> Hi Chris, thanks for looking. > 1) NetworkInterface.c > > I?m not sure that the close is really necessary, since a JNI pending > exception can only be thrown is sock is less than 0. I think just > removing the ' && (*env)->ExceptionOccurred(env)? from the original > if statement should be sufficient, no? I think you are right. An exception can only occur if socket is less than 0. There is one case where socket could be less than 0 and no exception occurred. In that case we'd probably see an exception later on. But I think it would be fine to return NULL in case socket is < 0. Generally, this coding needs to be revisited in order to make it work for IPv6 only systems. We should do that when finishing up bug 8148424 [1]. > 2) net_util.c > > getInet6Address_scopeid_set should CHECK_NULL_RETURN(holder, JNI_FALSE)? > getInet6Address_scopeid now returns an unsigned in, why CHECK_NULL_RETURN(holder, -1)? > > Some of this, existing, code seems a little dubious. > Good catch. The CHECK_NULL_RETURN macros need adaption. The reason why getInet6Address_scopeid should return unsigned int is that the struct sockaddr_in6 is also using unsigned int for the scope, e.g. on Linux [2] or Windows [3]. I've addressed your points in http://cr.openjdk.java.net/~clanger/webrevs/8170544.2/ Would you want to run this through JPRT again? I would go and push it towards the end of the week. Best regards Christoph [1] https://bugs.openjdk.java.net/browse/JDK-8148424 [2] http://man7.org/linux/man-pages/man7/ipv6.7.html [3] https://msdn.microsoft.com/en-us/library/windows/hardware/ff570824(v=vs.85).aspx From christoph.langer at sap.com Fri Jan 13 12:20:15 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Jan 2017 12:20:15 +0000 Subject: RFR: 8170544: Fix code scan findings in libnet References: <583F04DE.9060706@oracle.com> <703e4795f5bd4ba1afd2af60c090f409@DEWDFE13DE03.global.corp.sap> <4e7c5f041dda445abb2869c3da5def4b@DEROTE13DE08.global.corp.sap> <48B4053C-51F3-4BB3-A0E4-0AF07737DA0D@oracle.com> Message-ID: Hi, I finally pushed the change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f3115622562a Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 11. Januar 2017 16:50 > To: 'Chris Hegarty' > Cc: Lindenmaier, Goetz ; net- > dev at openjdk.java.net; Michael McMahon > Subject: RE: RFR: 8170544: Fix code scan findings in libnet > > Hi Chris, > > thanks for looking. > > > 1) NetworkInterface.c > > > > I?m not sure that the close is really necessary, since a JNI pending > > exception can only be thrown is sock is less than 0. I think just > > removing the ' && (*env)->ExceptionOccurred(env)? from the original > > if statement should be sufficient, no? > > I think you are right. An exception can only occur if socket is less than 0. There > is one case where socket could be less than 0 and no exception occurred. In > that case we'd probably see an exception later on. But I think it would be fine to > return NULL in case socket is < 0. Generally, this coding needs to be revisited in > order to make it work for IPv6 only systems. We should do that when finishing > up bug 8148424 [1]. > > > 2) net_util.c > > > > getInet6Address_scopeid_set should CHECK_NULL_RETURN(holder, > JNI_FALSE)? > > getInet6Address_scopeid now returns an unsigned in, why > CHECK_NULL_RETURN(holder, -1)? > > > > Some of this, existing, code seems a little dubious. > > > > Good catch. The CHECK_NULL_RETURN macros need adaption. The reason why > getInet6Address_scopeid should return unsigned int is that the struct > sockaddr_in6 is also using unsigned int for the scope, e.g. on Linux [2] or > Windows [3]. > > I've addressed your points in > http://cr.openjdk.java.net/~clanger/webrevs/8170544.2/ Would you want to > run this through JPRT again? > > I would go and push it towards the end of the week. > > Best regards > Christoph > > [1] https://bugs.openjdk.java.net/browse/JDK-8148424 > [2] http://man7.org/linux/man-pages/man7/ipv6.7.html > [3] https://msdn.microsoft.com/en- > us/library/windows/hardware/ff570824(v=vs.85).aspx > From michael.x.mcmahon at oracle.com Fri Jan 13 16:37:07 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 13 Jan 2017 16:37:07 +0000 Subject: RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404 Message-ID: <58790233.2090502@oracle.com> Could I get the following test change reviewed please? Macos test failure almost certainly caused by the use of a system proxy. Fix is to explicitly specify that proxy must not be used. http://cr.openjdk.java.net/~michaelm/8172253/webrev.1/ Thanks, Michael From daniel.fuchs at oracle.com Fri Jan 13 16:42:20 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 13 Jan 2017 16:42:20 +0000 Subject: RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404 In-Reply-To: <58790233.2090502@oracle.com> References: <58790233.2090502@oracle.com> Message-ID: <29ddefbc-4447-792d-62bf-c1474054178b@oracle.com> On 13/01/17 16:37, Michael McMahon wrote: > Could I get the following test change reviewed please? > > Macos test failure almost certainly caused by the use of a system proxy. > Fix is to explicitly specify that proxy must not be used. > > http://cr.openjdk.java.net/~michaelm/8172253/webrev.1/ > > Thanks, > Michael Looks good to me Michael. best regards, -- daniel From chris.hegarty at oracle.com Fri Jan 13 16:46:34 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 13 Jan 2017 16:46:34 +0000 Subject: RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404 In-Reply-To: <29ddefbc-4447-792d-62bf-c1474054178b@oracle.com> References: <58790233.2090502@oracle.com> <29ddefbc-4447-792d-62bf-c1474054178b@oracle.com> Message-ID: On 13/01/17 16:42, Daniel Fuchs wrote: > On 13/01/17 16:37, Michael McMahon wrote: >> Could I get the following test change reviewed please? >> >> Macos test failure almost certainly caused by the use of a system proxy. >> Fix is to explicitly specify that proxy must not be used. >> >> http://cr.openjdk.java.net/~michaelm/8172253/webrev.1/ >> >> Thanks, >> Michael > > Looks good to me Michael. +1 -Chris. From vyom.tewari at oracle.com Mon Jan 16 09:10:29 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Mon, 16 Jan 2017 14:40:29 +0530 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming Message-ID: Hi All, Please review below the small fix for the issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 The compatibility impact is minimum as no code in JDK is currently depend on it. I will file a CCC today. Thanks, Vyom --- a/src/java.naming/share/classes/javax/naming/CompoundName.java Fri Dec 23 09:31:24 2016 +0530 +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java Mon Jan 16 13:36:48 2017 +0530 @@ -153,7 +153,7 @@ * This field is initialized by the constructors and cannot be null. * It should be treated as a read-only variable by subclasses. */ - protected transient NameImpl impl; + private transient NameImpl impl; /** * Syntax properties for this compound name. * This field is initialized by the constructors and cannot be null. From Alan.Bateman at oracle.com Mon Jan 16 09:30:45 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Jan 2017 09:30:45 +0000 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming In-Reply-To: References: Message-ID: <279f82dd-a107-1f6c-eea2-2a0acf430538@oracle.com> On 16/01/2017 09:10, Vyom Tewari wrote: > Hi All, > > Please review below the small fix for the issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 > > The compatibility impact is minimum as no code in JDK is currently > depend on it. I think this is okay, it is technically an API change but I can't think why anyone extending CompoundName would rely on this. -Alan From chris.hegarty at oracle.com Mon Jan 16 09:56:16 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Jan 2017 09:56:16 +0000 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming In-Reply-To: References: Message-ID: Looks good. Thanks Vyom. -Chris. > On 16 Jan 2017, at 09:10, Vyom Tewari wrote: > > Hi All, > > Please review below the small fix for the issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 > > The compatibility impact is minimum as no code in JDK is currently depend on it. > > I will file a CCC today. > > Thanks, > > Vyom > > > --- a/src/java.naming/share/classes/javax/naming/CompoundName.java Fri Dec 23 09:31:24 2016 +0530 > +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java Mon Jan 16 13:36:48 2017 +0530 > @@ -153,7 +153,7 @@ > * This field is initialized by the constructors and cannot be null. > * It should be treated as a read-only variable by subclasses. > */ > - protected transient NameImpl impl; > + private transient NameImpl impl; > /** > * Syntax properties for this compound name. > * This field is initialized by the constructors and cannot be null. > From arno.zeller at sap.com Mon Jan 16 11:23:21 2017 From: arno.zeller at sap.com (Zeller, Arno) Date: Mon, 16 Jan 2017 11:23:21 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> Message-ID: <851663e383a24496aeff8e9f09f5045a@DEROTE13DE10.global.corp.sap> Hi Michael and Chris, I see that in with "RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404" you fix a problem on macOS that does occur, because macOS is the only platform that sets a default proxy from the system settings. On all other platforms the system settings are only used if -Djava.net.useSystemProxies is set to true. Do you know if there is a reason behind this behavior? I would suggest that all platforms behave similar? A reason could be that Mac users are often desktop users that are happy to have the VM use their system settings by default. But I guess this will apply for Windows desktop Users too and even for Linux or Solaris users. My webrev keeps the old behavior on macOS but I can change it :-) The current behavior in the webrev is: Default - without any properties: - macOS: If a proxy was manually added in the system settings it is used to populate the http.proxyHost/Port,... properties (will not work with an auto config URL aka PAC file or WPAD settings). - all other platforms: no proxy. java.net.useSystemProxies=true: - macOS and Windows - use System functionality to get a proxy lists for a given URL. This works now with PAC files or WPAD settings. - All UNIX versions excluding macOS: if Gnome 2.0 is configured to use a proxy we use the system functionality (available since gio lib 2.26) or we read the settings from gconf and use them to populate the http.proxyHost/Port,... properties - the later will again not work with PAC files or WPAD. http.proxyHost/Port,... properties are set: - On all platforms these properties have highest priority and will disable the use of system settings. Of course by changing the default behavior we would behave incompatible to old releases. What do you think shall be done? Another thing to improve could be the usage of the environment variables on UNIX system. Currently they are ignored, but It is pretty easy to parse http_proxy, https_proxy, ftp_proxy and no_proxy environment variables to set the default proxy properties on UNIX. My experience is that these variables are used more often than the gnome settings. Best regards, Arno >-----Original Message----- >From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >Zeller, Arno >Sent: Mittwoch, 11. Januar 2017 15:21 >To: Chris Hegarty >Cc: net-dev at openjdk.java.net >Subject: RE: RFR:8170868: DefaultProxySelector should use system defaults on >Windows, MacOS and Gnome > >Hi Chris, > >I have addressed your comments in a new webrev. Can you please have a >look at this one? > >http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ > >I created src/java.base/share/native/libnet/proxy_util.c/h and these files >contain now the common used native parts. >And I rewrote the code to return an array of Proxy objects from native code - >so I do no longer call back to Java to add an object to the list. > >Best regards, >Arno > >>-----Original Message----- >>From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>Sent: Dienstag, 3. Januar 2017 15:04 >>To: Zeller, Arno >>Cc: net-dev at openjdk.java.net >>Subject: Re: RFR:8170868: DefaultProxySelector should use system >>defaults on Windows, MacOS and Gnome >> >>Arno, >> >>> On 27 Dec 2016, at 11:44, Zeller, Arno wrote: >>> >>> Hi Chris, >>> >>> Thanks for having a look at my change: >>> >>>> 1) It seems awful to have to deal with LinkedList in native code. How >>>> about returning an array from native, and then converting that into >>>> whatever list type is appropriate at the Java level. >>> With the current implementation on Mac I do not know upfront how many >>items the list will contain and therefore I preferred to use the >>LinkedList from native code. >>> I can of course change the implementation on Mac to first generate a >>> fully >>resolved native list and then I can use NewObjectArray to generate an >>Array of Proxy objects to return. This will avoid calling to java to >>add an element to the list. Do you think this will be better? >> >>Yes. Thanks. >> >>>> 2) I would prefer the use of List.of(...), and list.of() for empty, since >>>> these are immutable and efficient list implementations. >>> I thought about that but I tried to not return an immutable List >>> because the >>Javadoc of Proxy.select does not state anything about the returned List >>(if it is immutable or not) and I feared to break compatibility by >>returning an immutable List. >>> If you think this is no problem I will of course prefer to always >>> return the >>same immutable NO_PROXY list object. >> >>I would prefer an immutable list. Maybe we file, a separate, issue to >>amend the spec to say "returns an immutable list ??. >> >>>> 3) Is the comment ?Inspired ...? necessary / appropriate? >>> I will change it to the comment proposed by Volker. >> >>Ok. >> >>>> 4) Can some of the native initialization code be moved to a platform >>>> independent location, to remove duplication? >>> Would it be ok if I move the definition of the static variables and >>> the >>implementation of 'static int initJavaClass(...)' to a header file in >>the shared branch. I.e. >>src/java.base/shared/native/libnet/DefaultProxySelector.h and include this >in the MacOSX, Windows and the Unix implementations? >> >>Yes. >> >>>> 5) The new file has a shared copyright header. I see similar SAP >>>> headers in a few files, but none shared with the Oracle header. >>>> How did you arrive at this format? >>> The format was suggested to me by Volker :-) >> >>Ok. >> >>-Chris. From Roger.Riggs at Oracle.com Tue Jan 17 15:50:39 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 17 Jan 2017 10:50:39 -0500 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming In-Reply-To: References: Message-ID: Hi Vyom, Please also correct or remove the comment saying it should be treated as read-only by subclasses. Roger On 1/16/2017 4:56 AM, Chris Hegarty wrote: > Looks good. Thanks Vyom. > > -Chris. > >> On 16 Jan 2017, at 09:10, Vyom Tewari wrote: >> >> Hi All, >> >> Please review below the small fix for the issue. >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 >> >> The compatibility impact is minimum as no code in JDK is currently depend on it. >> >> I will file a CCC today. >> >> Thanks, >> >> Vyom >> >> >> --- a/src/java.naming/share/classes/javax/naming/CompoundName.java Fri Dec 23 09:31:24 2016 +0530 >> +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java Mon Jan 16 13:36:48 2017 +0530 >> @@ -153,7 +153,7 @@ >> * This field is initialized by the constructors and cannot be null. >> * It should be treated as a read-only variable by subclasses. >> */ >> - protected transient NameImpl impl; >> + private transient NameImpl impl; >> /** >> * Syntax properties for this compound name. >> * This field is initialized by the constructors and cannot be null. >> From vyom.tewari at oracle.com Wed Jan 18 06:47:15 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Wed, 18 Jan 2017 12:17:15 +0530 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming In-Reply-To: References: Message-ID: Hi Roger, Thanks for the review i remove the comment saying it should be treated as read only. Please find below the latest diff. Thanks, Vyom --- a/src/java.naming/share/classes/javax/naming/CompoundName.java Fri Dec 23 09:31:24 2016 +0530 +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java Wed Jan 18 12:14:25 2017 +0530 @@ -149,11 +149,10 @@ public class CompoundName implements Name { /** - * Implementation of this compound name. - * This field is initialized by the constructors and cannot be null. - * It should be treated as a read-only variable by subclasses. - */ - protected transient NameImpl impl; + * Implementation of this compound name. This field is initialized by the + * constructors and cannot be null. + */ + private transient NameImpl impl; /** * Syntax properties for this compound name. * This field is initialized by the constructors and cannot be null. On Tuesday 17 January 2017 09:20 PM, Roger Riggs wrote: > Hi Vyom, > > Please also correct or remove the comment saying it should be treated > as read-only by subclasses. > > Roger > > > On 1/16/2017 4:56 AM, Chris Hegarty wrote: >> Looks good. Thanks Vyom. >> >> -Chris. >> >>> On 16 Jan 2017, at 09:10, Vyom Tewari wrote: >>> >>> Hi All, >>> >>> Please review below the small fix for the issue. >>> >>> BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 >>> >>> The compatibility impact is minimum as no code in JDK is currently >>> depend on it. >>> >>> I will file a CCC today. >>> >>> Thanks, >>> >>> Vyom >>> >>> >>> --- a/src/java.naming/share/classes/javax/naming/CompoundName.java >>> Fri Dec 23 09:31:24 2016 +0530 >>> +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java >>> Mon Jan 16 13:36:48 2017 +0530 >>> @@ -153,7 +153,7 @@ >>> * This field is initialized by the constructors and cannot be >>> null. >>> * It should be treated as a read-only variable by subclasses. >>> */ >>> - protected transient NameImpl impl; >>> + private transient NameImpl impl; >>> /** >>> * Syntax properties for this compound name. >>> * This field is initialized by the constructors and cannot be >>> null. >>> > From Roger.Riggs at Oracle.com Wed Jan 18 14:30:30 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 18 Jan 2017 09:30:30 -0500 Subject: RFR: 8167178 Exported elements referring to inaccessible types in java.naming In-Reply-To: References: Message-ID: Looks good. Thanks, Roger On 1/18/2017 1:47 AM, Vyom Tewari wrote: > Hi Roger, > > Thanks for the review i remove the comment saying it should be treated > as read only. Please find below the latest diff. > > Thanks, > > Vyom > > --- a/src/java.naming/share/classes/javax/naming/CompoundName.java Fri > Dec 23 09:31:24 2016 +0530 > +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java Wed > Jan 18 12:14:25 2017 +0530 > @@ -149,11 +149,10 @@ > public class CompoundName implements Name { > > /** > - * Implementation of this compound name. > - * This field is initialized by the constructors and cannot be > null. > - * It should be treated as a read-only variable by subclasses. > - */ > - protected transient NameImpl impl; > + * Implementation of this compound name. This field is > initialized by the > + * constructors and cannot be null. > + */ > + private transient NameImpl impl; > /** > * Syntax properties for this compound name. > * This field is initialized by the constructors and cannot be > null. > > > On Tuesday 17 January 2017 09:20 PM, Roger Riggs wrote: >> Hi Vyom, >> >> Please also correct or remove the comment saying it should be treated >> as read-only by subclasses. >> >> Roger >> >> >> On 1/16/2017 4:56 AM, Chris Hegarty wrote: >>> Looks good. Thanks Vyom. >>> >>> -Chris. >>> >>>> On 16 Jan 2017, at 09:10, Vyom Tewari wrote: >>>> >>>> Hi All, >>>> >>>> Please review below the small fix for the issue. >>>> >>>> BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 >>>> >>>> The compatibility impact is minimum as no code in JDK is currently >>>> depend on it. >>>> >>>> I will file a CCC today. >>>> >>>> Thanks, >>>> >>>> Vyom >>>> >>>> >>>> --- a/src/java.naming/share/classes/javax/naming/CompoundName.java >>>> Fri Dec 23 09:31:24 2016 +0530 >>>> +++ b/src/java.naming/share/classes/javax/naming/CompoundName.java >>>> Mon Jan 16 13:36:48 2017 +0530 >>>> @@ -153,7 +153,7 @@ >>>> * This field is initialized by the constructors and cannot >>>> be null. >>>> * It should be treated as a read-only variable by subclasses. >>>> */ >>>> - protected transient NameImpl impl; >>>> + private transient NameImpl impl; >>>> /** >>>> * Syntax properties for this compound name. >>>> * This field is initialized by the constructors and cannot >>>> be null. >>>> >> > From chris.hegarty at oracle.com Tue Jan 24 14:08:20 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 24 Jan 2017 14:08:20 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules Message-ID: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> As per the guidance in JEP 11 [1], the javadoc for types in incubator modules should have a clear and explicit warning notice. To that end, I?ve added a simple inline taglet that can be used to effectively inject a standard notice, and applied it to all public types in the HTTP module ( I?ll cleanup the line width formatting before pushing ). http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. P.S. this work is, somewhat, in preparation for when we move to a single documentation bundle [2]. [1] http://openjdk.java.net/jeps/11 [2] http://openjdk.java.net/jeps/299 From erik.joelsson at oracle.com Tue Jan 24 16:44:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Jan 2017 17:44:52 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: Hello, Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. /Erik On 2017-01-24 15:08, Chris Hegarty wrote: > As per the guidance in JEP 11 [1], the javadoc for types in > incubator modules should have a clear and explicit warning > notice. To that end, I?ve added a simple inline taglet that can > be used to effectively inject a standard notice, and applied it > to all public types in the HTTP module ( I?ll cleanup the line > width formatting before pushing ). > > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > > P.S. this work is, somewhat, in preparation for when we move > to a single documentation bundle [2]. > > [1] http://openjdk.java.net/jeps/11 > [2] http://openjdk.java.net/jeps/299 From michael.x.mcmahon at oracle.com Tue Jan 24 17:45:33 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 24 Jan 2017 17:45:33 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: Hi Chris As regards the networking changes, they look fine to me. As discussed off list, I think the link generated by the @Incubating tag might possibly point to a new page in the docs bundle rather than directly to the JEP 11 page. But, that can be the subject of another change. Thanks, Michael. On 24/01/17 14:08, Chris Hegarty wrote: > As per the guidance in JEP 11 [1], the javadoc for types in > incubator modules should have a clear and explicit warning > notice. To that end, I?ve added a simple inline taglet that can > be used to effectively inject a standard notice, and applied it > to all public types in the HTTP module ( I?ll cleanup the line > width formatting before pushing ). > > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > > P.S. this work is, somewhat, in preparation for when we move > to a single documentation bundle [2]. > > [1] http://openjdk.java.net/jeps/11 > [2] http://openjdk.java.net/jeps/299 From chris.hegarty at oracle.com Wed Jan 25 12:51:16 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 25 Jan 2017 12:51:16 +0000 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> Message-ID: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> > On 24 Jan 2017, at 16:44, Erik Joelsson wrote: > > Hello, > > Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. Updated in place http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. > /Erik > > > On 2017-01-24 15:08, Chris Hegarty wrote: >> As per the guidance in JEP 11 [1], the javadoc for types in >> incubator modules should have a clear and explicit warning >> notice. To that end, I?ve added a simple inline taglet that can >> be used to effectively inject a standard notice, and applied it >> to all public types in the HTTP module ( I?ll cleanup the line >> width formatting before pushing ). >> >> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >> >> -Chris. >> >> P.S. this work is, somewhat, in preparation for when we move >> to a single documentation bundle [2]. >> >> [1] http://openjdk.java.net/jeps/11 >> [2] http://openjdk.java.net/jeps/299 > From erik.joelsson at oracle.com Wed Jan 25 13:39:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 25 Jan 2017 14:39:48 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> Message-ID: <09f550c4-87e5-0129-229e-a312b7af90f9@oracle.com> Thanks, looks good now. /Erik On 2017-01-25 13:51, Chris Hegarty wrote: >> On 24 Jan 2017, at 16:44, Erik Joelsson wrote: >> >> Hello, >> >> Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. > Updated in place > http://cr.openjdk.java.net/~chegar/incubator_taglet/ > > -Chris. > >> /Erik >> >> >> On 2017-01-24 15:08, Chris Hegarty wrote: >>> As per the guidance in JEP 11 [1], the javadoc for types in >>> incubator modules should have a clear and explicit warning >>> notice. To that end, I?ve added a simple inline taglet that can >>> be used to effectively inject a standard notice, and applied it >>> to all public types in the HTTP module ( I?ll cleanup the line >>> width formatting before pushing ). >>> >>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>> >>> -Chris. >>> >>> P.S. this work is, somewhat, in preparation for when we move >>> to a single documentation bundle [2]. >>> >>> [1] http://openjdk.java.net/jeps/11 >>> [2] http://openjdk.java.net/jeps/299 From volker.simonis at gmail.com Thu Jan 26 08:30:10 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Jan 2017 09:30:10 +0100 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> Message-ID: 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 comments in a new webrev. Can you please have a look at this one? > > http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ > > I created src/java.base/share/native/libnet/proxy_util.c/h and these files contain now the common used native parts. > And I rewrote the code to return an array of Proxy objects from native code - so I do no longer call back to Java to > add an object to the list. > > Best regards, > Arno > >>-----Original Message----- >>From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>Sent: Dienstag, 3. Januar 2017 15:04 >>To: Zeller, Arno >>Cc: net-dev at openjdk.java.net >>Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >>on Windows, MacOS and Gnome >> >>Arno, >> >>> On 27 Dec 2016, at 11:44, Zeller, Arno wrote: >>> >>> Hi Chris, >>> >>> Thanks for having a look at my change: >>> >>>> 1) It seems awful to have to deal with LinkedList in native code. How >>>> about returning an array from native, and then converting that into >>>> whatever list type is appropriate at the Java level. >>> With the current implementation on Mac I do not know upfront how many >>items the list will contain and therefore I preferred to use the LinkedList from >>native code. >>> I can of course change the implementation on Mac to first generate a fully >>resolved native list and then I can use NewObjectArray to generate an Array >>of Proxy objects to return. This will avoid calling to java to add an element to >>the list. Do you think this will be better? >> >>Yes. Thanks. >> >>>> 2) I would prefer the use of List.of(...), and list.of() for empty, since >>>> these are immutable and efficient list implementations. >>> I thought about that but I tried to not return an immutable List because the >>Javadoc of Proxy.select does not state anything about the returned List (if it is >>immutable or not) and I feared to break compatibility by returning an >>immutable List. >>> If you think this is no problem I will of course prefer to always return the >>same immutable NO_PROXY list object. >> >>I would prefer an immutable list. Maybe we file, a separate, issue to amend >>the spec to say "returns an immutable list ??. >> >>>> 3) Is the comment ?Inspired ...? necessary / appropriate? >>> I will change it to the comment proposed by Volker. >> >>Ok. >> >>>> 4) Can some of the native initialization code be moved to a platform >>>> independent location, to remove duplication? >>> Would it be ok if I move the definition of the static variables and the >>implementation of 'static int initJavaClass(...)' to a header file in the shared >>branch. I.e. src/java.base/shared/native/libnet/DefaultProxySelector.h and >>include this in the MacOSX, Windows and the Unix implementations? >> >>Yes. >> >>>> 5) The new file has a shared copyright header. I see similar SAP >>>> headers in a few files, but none shared with the Oracle header. >>>> How did you arrive at this format? >>> The format was suggested to me by Volker :-) >> >>Ok. >> >>-Chris. From chris.hegarty at oracle.com Thu Jan 26 09:52:13 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 26 Jan 2017 09:52:13 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <851663e383a24496aeff8e9f09f5045a@DEROTE13DE10.global.corp.sap> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <851663e383a24496aeff8e9f09f5045a@DEROTE13DE10.global.corp.sap> Message-ID: <937A702D-968C-4B67-A914-6CE84AD6191B@oracle.com> Arno, > On 16 Jan 2017, at 11:23, Zeller, Arno wrote: > > Hi Michael and Chris, > > I see that in with "RFR: 8172253 SetIfModifiedSince.java test fails with http return code 404" you fix a problem > on macOS that does occur, because macOS is the only platform that sets a default proxy from the system > settings. On all other platforms the system settings are only used if -Djava.net.useSystemProxies is set to true. > > Do you know if there is a reason behind this behaviour? The system proxies are used, by default, on Mac OS X to maintain compatibility from Apple's Java 6 to OpenJDK 7 with Mac support ( 7 is the first OpenJDK version that supports Mac ). > I would suggest that all platforms behave similar? Maybe early on in a future release we could attempt to do this. > A > reason could be that Mac users are often desktop users that are happy to have the VM use their system > settings by default. But I guess this will apply for Windows desktop Users too and even for Linux or Solaris > users. > > My webrev keeps the old behavior on macOS but I can change it :-) Please keep the current behaviour, as you are proposing. > The current behavior in the webrev is: > > Default - without any properties: > - macOS: If a proxy was manually added in the system settings it is used to populate the http.proxyHost/Port,... > properties (will not work with an auto config URL aka PAC file or WPAD settings). > - all other platforms: no proxy. > > java.net.useSystemProxies=true: > - macOS and Windows - use System functionality to get a proxy lists for a given URL. This works now with PAC > files or WPAD settings. > - All UNIX versions excluding macOS: if Gnome 2.0 is configured to use a proxy we use the system functionality > (available since gio lib 2.26) or we read the settings from gconf and use them to populate the > http.proxyHost/Port,... properties - the later will again not work with PAC files or WPAD. > > http.proxyHost/Port,... properties are set: > - On all platforms these properties have highest priority and will disable the use of system settings. > > Of course by changing the default behavior we would behave incompatible to old releases. What do you think > shall be done? Not in 9, but maybe in a future release. > Another thing to improve could be the usage of the environment variables on UNIX system. Currently they are > ignored, but It is pretty easy to parse http_proxy, https_proxy, ftp_proxy and no_proxy environment variables > to set the default proxy properties on UNIX. My experience is that these variables are used more often than > the gnome settings. My personal preference is to move more towards the system?s proxies, rather than yet another way of setting proxies. -Chris. > Best regards, > Arno > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >> Zeller, Arno >> Sent: Mittwoch, 11. Januar 2017 15:21 >> To: Chris Hegarty >> Cc: net-dev at openjdk.java.net >> Subject: RE: RFR:8170868: DefaultProxySelector should use system defaults on >> Windows, MacOS and Gnome >> >> Hi Chris, >> >> I have addressed your comments in a new webrev. Can you please have a >> look at this one? >> >> http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ >> >> I created src/java.base/share/native/libnet/proxy_util.c/h and these files >> contain now the common used native parts. >> And I rewrote the code to return an array of Proxy objects from native code - >> so I do no longer call back to Java to add an object to the list. >> >> Best regards, >> Arno >> >>> -----Original Message----- >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>> Sent: Dienstag, 3. Januar 2017 15:04 >>> To: Zeller, Arno >>> Cc: net-dev at openjdk.java.net >>> Subject: Re: RFR:8170868: DefaultProxySelector should use system >>> defaults on Windows, MacOS and Gnome >>> >>> Arno, >>> >>>> On 27 Dec 2016, at 11:44, Zeller, Arno wrote: >>>> >>>> Hi Chris, >>>> >>>> Thanks for having a look at my change: >>>> >>>>> 1) It seems awful to have to deal with LinkedList in native code. How >>>>> about returning an array from native, and then converting that into >>>>> whatever list type is appropriate at the Java level. >>>> With the current implementation on Mac I do not know upfront how many >>> items the list will contain and therefore I preferred to use the >>> LinkedList from native code. >>>> I can of course change the implementation on Mac to first generate a >>>> fully >>> resolved native list and then I can use NewObjectArray to generate an >>> Array of Proxy objects to return. This will avoid calling to java to >>> add an element to the list. Do you think this will be better? >>> >>> Yes. Thanks. >>> >>>>> 2) I would prefer the use of List.of(...), and list.of() for empty, since >>>>> these are immutable and efficient list implementations. >>>> I thought about that but I tried to not return an immutable List >>>> because the >>> Javadoc of Proxy.select does not state anything about the returned List >>> (if it is immutable or not) and I feared to break compatibility by >>> returning an immutable List. >>>> If you think this is no problem I will of course prefer to always >>>> return the >>> same immutable NO_PROXY list object. >>> >>> I would prefer an immutable list. Maybe we file, a separate, issue to >>> amend the spec to say "returns an immutable list ??. >>> >>>>> 3) Is the comment ?Inspired ...? necessary / appropriate? >>>> I will change it to the comment proposed by Volker. >>> >>> Ok. >>> >>>>> 4) Can some of the native initialization code be moved to a platform >>>>> independent location, to remove duplication? >>>> Would it be ok if I move the definition of the static variables and >>>> the >>> implementation of 'static int initJavaClass(...)' to a header file in >>> the shared branch. I.e. >>> src/java.base/shared/native/libnet/DefaultProxySelector.h and include this >> in the MacOSX, Windows and the Unix implementations? >>> >>> Yes. >>> >>>>> 5) The new file has a shared copyright header. I see similar SAP >>>>> headers in a few files, but none shared with the Oracle header. >>>>> How did you arrive at this format? >>>> The format was suggested to me by Volker :-) >>> >>> Ok. >>> >>> -Chris. From christoph.langer at sap.com Thu Jan 26 10:02:38 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Jan 2017 10:02:38 +0000 Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows Message-ID: <06ebca5f8e1141ad9e1688d0462cb98a@derote13de46.global.corp.sap> Hi Chris, Michael, as I consider this change final from my side and the jdk10 forest is open now, I guess it is a good point to come back to this. I personally would prefer if I could still submit it to jdk9, given that it is automatically consolidated to jdk10 and the code base would remain the same. The change set is only a cleanup to the Inet*AddressImpl.c coding and should be quite manageable. The same goes for this one: http://mail.openjdk.java.net/pipermail/net-dev/2016-December/010571.html In any case, I'd like you to decide this now and give me a review in short term, that I can get it out of my head. :) Thanks & Best regards Christoph From: Langer, Christoph Sent: Mittwoch, 21. Dezember 2016 15:57 To: net-dev at openjdk.java.net Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows Hi again, after pushing the change for 8171077 (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/24f8703890b2), I have updated my patch for 8167457 and I have also updated the bug description to reflect the reduced scope. Bug: https://bugs.openjdk.java.net/browse/JDK-8167457 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167457.0/ The change now merely is code cleanup which should not change the current behavior apart from removing the isspace(hostname[0]) check and the isDottedIPAddress check in Java_java_net_Inet4AddressImpl_lookupAllHostAddr. But testing lets me think it is not needed any longer for the supported Windows versions of JDK9. Same as with 8167420, from my point of view this change is ready to push and it runs nightly in our builds/tests of OpenJDK on several platforms. Though I guess you want to postpone this to JDK10, I'd be glad if you could still consider it for JDK9. But I won't pressure otherwise ;-) Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Jan 26 11:45:36 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Jan 2017 12:45:36 +0100 Subject: RFR [9] Warning notice for types in Incubator Modules In-Reply-To: <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> References: <88605417-EA37-4FE2-9B45-5828BD357179@oracle.com> <37E3BDFA-3AF5-4A92-BEB8-35C9D3D27A16@oracle.com> Message-ID: <5e20457b-8b10-7b45-a3bc-f6b9b1a57502@oracle.com> On 2017-01-25 13:51, Chris Hegarty wrote: >> On 24 Jan 2017, at 16:44, Erik Joelsson wrote: >> >> Hello, >> >> Build changes look good except for one thing. In Javadoc.gmk, the dependency on $(BUILD_TOOLS_JDK) needs to be set for $$($1_INDEX_FILE) (on line 317), where the actual recipes are created. Setting it on the phony docs-javadoc target will not help incremental builds. > Updated in place > http://cr.openjdk.java.net/~chegar/incubator_taglet/ It's not ideal that a top-level target has dependencies from the JDK repo, but since we have no or few pre-existing top-level tools, I understand if you hesitate to add a new framework for such tools. If we ever do introduce more such tools, I think we should move this along. I think the new -taglet options to the DEFAULT_JAVADOC_OPTIONS variable. As the documentation says, the DEFAULT_JAVADOC_TAGS is there to specify the ordering of tags in the output. Unless the -taglet options implicitly generates one or more -tag options in it's place, that's the wrong place to put it. If it does, perhaps a comment indicating this hidden behavior would be in place. In the line: "$$($1_INDEX_FILE): $(BUILD_TOOLS_JDK) $$($1_VARDEPS_FILE) $$($1_PACKAGE_DEPS) $$($1_DEPS)", please use a double $ ($$) for all variables. While technically not necessary in this particular case, it's misleading and we've had our share of bugs due to single $ in eval'd macros. In the line: "docs-javadoc: $(BUILD_TOOLS_JDK) $(TARGETS)", please remove the reference to BUILD_TOOLS_JDK. It is not needed. /Magnus > > -Chris. > >> /Erik >> >> >> On 2017-01-24 15:08, Chris Hegarty wrote: >>> As per the guidance in JEP 11 [1], the javadoc for types in >>> incubator modules should have a clear and explicit warning >>> notice. To that end, I?ve added a simple inline taglet that can >>> be used to effectively inject a standard notice, and applied it >>> to all public types in the HTTP module ( I?ll cleanup the line >>> width formatting before pushing ). >>> >>> http://cr.openjdk.java.net/~chegar/incubator_taglet/ >>> >>> -Chris. >>> >>> P.S. this work is, somewhat, in preparation for when we move >>> to a single documentation bundle [2]. >>> >>> [1] http://openjdk.java.net/jeps/11 >>> [2] http://openjdk.java.net/jeps/299 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Thu Jan 26 14:50:44 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 26 Jan 2017 14:50:44 +0000 Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows In-Reply-To: <06ebca5f8e1141ad9e1688d0462cb98a@derote13de46.global.corp.sap> References: <06ebca5f8e1141ad9e1688d0462cb98a@derote13de46.global.corp.sap> Message-ID: <588A0CC4.4020101@oracle.com> Christoph, I would prefer to not push these native code change to JDK 9 at this stage. They look fine for JDK 10 though. Consider them both reviewed. Thanks Michael. On 26/01/2017, 10:02, Langer, Christoph wrote: > > Hi Chris, Michael, > > as I consider this change final from my side and the jdk10 forest is > open now, I guess it is a good point to come back to this. > > I personally would prefer if I could still submit it to jdk9, given > that it is automatically consolidated to jdk10 and the code base would > remain the same. The change set is only a cleanup to the > Inet*AddressImpl.c coding and should be quite manageable. > > The same goes for this one: > http://mail.openjdk.java.net/pipermail/net-dev/2016-December/010571.html > > In any case, I'd like you to decide this now and give me a review in > short term, that I can get it out of my head. J > > Thanks & Best regards > > Christoph > > *From:*Langer, Christoph > *Sent:* Mittwoch, 21. Dezember 2016 15:57 > *To:* net-dev at openjdk.java.net > *Subject:* RFR(M): 8167457: Fixes for InetAddressImpl native coding on > Windows > > Hi again, > > after pushing the change for 8171077 > (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/24f8703890b2), I have > updated my patch for 8167457 and I have also updated the bug > description to reflect the reduced scope. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167457 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167457.0/ > > > The change now merely is code cleanup which should not change the > current behavior apart from removing the isspace(hostname[0]) check > and the isDottedIPAddress check in > Java_java_net_Inet4AddressImpl_lookupAllHostAddr. But testing lets me > think it is not needed any longer for the supported Windows versions > of JDK9. > > Same as with 8167420, from my point of view this change is ready to > push and it runs nightly in our builds/tests of OpenJDK on several > platforms. Though I guess you want to postpone this to JDK10, I'd be > glad if you could still consider it for JDK9. But I won't pressure > otherwise ;-) > > Thanks & Best regards > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jan 26 16:12:05 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Jan 2017 16:12:05 +0000 Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows In-Reply-To: <588A0CC4.4020101@oracle.com> References: <06ebca5f8e1141ad9e1688d0462cb98a@derote13de46.global.corp.sap> <588A0CC4.4020101@oracle.com> Message-ID: <1e16c8f8c84c4c789e41085c1bf71f5e@derote13de46.global.corp.sap> Hi Michael, Thanks for reviewing. So I'll push them in jdk10. Best regards Christoph From: Michael McMahon [mailto:michael.x.mcmahon at oracle.com] Sent: Donnerstag, 26. Januar 2017 15:51 To: Langer, Christoph Cc: Chris Hegarty ; net-dev at openjdk.java.net Subject: Re: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows Christoph, I would prefer to not push these native code change to JDK 9 at this stage. They look fine for JDK 10 though. Consider them both reviewed. Thanks Michael. On 26/01/2017, 10:02, Langer, Christoph wrote: Hi Chris, Michael, as I consider this change final from my side and the jdk10 forest is open now, I guess it is a good point to come back to this. I personally would prefer if I could still submit it to jdk9, given that it is automatically consolidated to jdk10 and the code base would remain the same. The change set is only a cleanup to the Inet*AddressImpl.c coding and should be quite manageable. The same goes for this one: http://mail.openjdk.java.net/pipermail/net-dev/2016-December/010571.html In any case, I'd like you to decide this now and give me a review in short term, that I can get it out of my head. :) Thanks & Best regards Christoph From: Langer, Christoph Sent: Mittwoch, 21. Dezember 2016 15:57 To: net-dev at openjdk.java.net Subject: RFR(M): 8167457: Fixes for InetAddressImpl native coding on Windows Hi again, after pushing the change for 8171077 (http://hg.openjdk.java.net/jdk9/dev/jdk/rev/24f8703890b2), I have updated my patch for 8167457 and I have also updated the bug description to reflect the reduced scope. Bug: https://bugs.openjdk.java.net/browse/JDK-8167457 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167457.0/ The change now merely is code cleanup which should not change the current behavior apart from removing the isspace(hostname[0]) check and the isDottedIPAddress check in Java_java_net_Inet4AddressImpl_lookupAllHostAddr. But testing lets me think it is not needed any longer for the supported Windows versions of JDK9. Same as with 8167420, from my point of view this change is ready to push and it runs nightly in our builds/tests of OpenJDK on several platforms. Though I guess you want to postpone this to JDK10, I'd be glad if you could still consider it for JDK9. But I won't pressure otherwise ;-) Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergei.kovalev at oracle.com Fri Jan 27 12:43:55 2017 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 27 Jan 2017 15:43:55 +0300 Subject: RFR(S): 8173475 : java/net/HttpURLConnection/SetAuthenticator tests have undeclared dependency on java.logging module Message-ID: <96807ec3-339d-6001-7779-ca2f0bef9a7f@oracle.com> Hi All, Please review a small fix for tests. BugID: https://bugs.openjdk.java.net/browse/JDK-8173475 WebRev: http://cr.openjdk.java.net/~skovalev/8173475/webrev.00/ Issue: Two tests fail in case of usage '--limit-module' command line option. Root cause: One of the files HTTPTest.java has dependency on java.logging module. Second tests HTTPSetAuthenticatorTest.java extends first one. Therefore we need to add dependency declaration to the both tests. -- With best regards, Sergei From chris.hegarty at oracle.com Fri Jan 27 14:11:09 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 27 Jan 2017 14:11:09 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> Message-ID: <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> Arno, On 11/01/17 14:21, Zeller, Arno wrote: > Hi Chris, > > I have addressed your comments in a new webrev. Can you please have a look at this one? > > http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ This is looking much better, thank you. Some smaller comments and observations ( I'm still reviewing and testing ): 1) With this change there may be network connections made to support WPAD and retrieve PAC files. This should be fine as system proxy settings are coming from a trusted source, i.e. the system. 2) unix/native/libnet/DefaultProxySelector.c You have changes to make g_strv_length available, but then count the proxies in the list manually. Maybe just use g_strv_length. Nit: L 167 / 358 parameter indentation 3) windows/native/libnet/DefaultProxySelector.c The HINTERNET session could be set lazily, for the case where there are no auto proxy settings. Not sure if it worth it though. The indentation of the main body of XXX_getSystemProxies could be reduced a little if: if (WinHttpGetIEProxyConfigForCurrentUser(&ie_proxy_config) == FALSE) return NULL; 4) macosx/native/libnet/DefaultProxySelector.c The indentation of the main body of XXX_getSystemProxies could be reduced a little if: proxyDicRef = CFNetworkCopySystemProxySettings(); if (proxyDicRef == NULL) return NULL; 5) I personally prefer the code of the old createProxy. Was there specific reason why you changed it? 6) Can you generally check the line lengths in all files, and try where possible to keep it below 100, e.g. some comments could easily be wrapped. 7) I would like to add jtreg tags to test/java/net/ProxySelector/ SystemProxies.java to have it run in any automated test systems. There would be no failure mode of this test, as it requires manually inspecting the output, but it would at least give some coverage to this new code. Something like: /* * @test * @bug 8170868 * @summary Basic test to provide some coverage of system proxy code. Will * always pass. Should be run manually for specific systems to inspect output. * @run/othervm -Djava.net.useSystemProxies=true SystemProxies */ -Chris. From arno.zeller at sap.com Mon Jan 30 15:31:52 2017 From: arno.zeller at sap.com (Zeller, Arno) Date: Mon, 30 Jan 2017 15:31:52 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> Message-ID: Hi Chris, thanks for your comments! I adjusted the change to contain your suggestions and slightly modified src/java.base/share/classes/java/net/doc-files/net-properties.html to refer to macOS . Also found some missing adjustments of the copyright year myself... >Some smaller comments and observations ( I'm still reviewing and testing ): ... >2) unix/native/libnet/DefaultProxySelector.c > > You have changes to make g_strv_length available, but then > count the proxies in the list manually. Maybe just use > g_strv_length. Removed reference to g_strv_length - I simply forgot to delete it after changing my code to iterate over the list. > Nit: L 167 / 358 parameter indentation Fixed. >3) windows/native/libnet/DefaultProxySelector.c > > The HINTERNET session could be set lazily, for the case > where there are no auto proxy settings. Not sure if it > worth it though. I would like to keep the current approach because it avoids the need of locking to ensure that the initialization is done only by one thread. > The indentation of the main body of XXX_getSystemProxies > could be reduced a little if: > if (WinHttpGetIEProxyConfigForCurrentUser(&ie_proxy_config) == FALSE) > return NULL; Done. >4) macosx/native/libnet/DefaultProxySelector.c > > The indentation of the main body of XXX_getSystemProxies > could be reduced a little if: > proxyDicRef = CFNetworkCopySystemProxySettings(); > if (proxyDicRef == NULL) > return NULL; Done. >5) I personally prefer the code of the old createProxy. Was there > specific reason why you changed it? Sorry for this - another leftover from a former change. I reverted back to the original. >6) Can you generally check the line lengths in all files, and try > where possible to keep it below 100, e.g. some comments could > easily be wrapped. Done. >7) I would like to add jtreg tags to test/java/net/ProxySelector/ > SystemProxies.java to have it run in any automated test systems. > There would be no failure mode of this test, as it requires > manually inspecting the output, but it would at least give some > coverage to this new code. Something like: > /* > * @test > * @bug 8170868 > * @summary Basic test to provide some coverage of system proxy code. >Will > * always pass. Should be run manually for specific systems to inspect >output. > * @run/othervm -Djava.net.useSystemProxies=true SystemProxies > */ Done. The new webrev can be found at: http://cr.openjdk.java.net/~clanger/webrevs/8170868.4/ Best regards, Arno From chris.hegarty at oracle.com Mon Jan 30 16:14:09 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 30 Jan 2017 16:14:09 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> Message-ID: <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> Arno, I found an issue on Windows when proxies are specified per-protocol, i.e. they are returned with their optional scheme set. I believe that the scheme should be checked, at least without this change FTP proxies were being returned for HTTP URL's, on my machine. $ hg -R jdk diff diff -r 07e07fecf383 src/java.base/windows/native/libnet/DefaultProxySelector.c --- a/src/java.base/windows/native/libnet/DefaultProxySelector.c Mon Jan 30 14:09:14 2017 +0000 +++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c Mon Jan 30 16:09:23 2017 +0000 @@ -99,6 +99,7 @@ * Returns the size of the array as int. */ static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, list_item **head) { + static const wchar_t separators[] = L"\t\r\n ;"; list_item *current = NULL; int nr_elems = 0; wchar_t *context = NULL; @@ -109,13 +110,26 @@ * The proxy server list contains one or more of the following strings separated by semicolons or whitespace. * ([=]["://"][":"]) */ - current_proxy = wcstok_s(win_proxy, L"; ", &context); - while (current_proxy != NULL) { + current_proxy = wcstok_s(win_proxy, separators, &context); + while (current_proxy != NULL) { LPWSTR pport; LPWSTR phost; int portVal = 0; wchar_t *next_proxy = NULL; list_item *proxy = NULL; + wchar_t* pos = NULL; + + /* Filter based on the scheme, if there is one */ + pos = wcschr(current_proxy, L'='); + if (pos) { + *pos = L'\0'; + if (wcscmp(current_proxy, pproto) != 0) { + current_proxy = wcstok_s(NULL, separators, &context); + continue; + } + current_proxy = pos + 1; + } /* Let's check for a scheme and ignore it. */ if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ -152,7 +166,7 @@ } } /* goto next proxy if available... */ - current_proxy = wcstok_s(NULL, L"; ", &context); + current_proxy = wcstok_s(NULL, separators, &context); } return nr_elems; } @@ -268,7 +282,6 @@ if (win_proxy != NULL) { wchar_t *context = NULL; int defport = 0; - WCHAR pproto[MAX_STR_LEN]; int nr_elems = 0; /** @@ -290,10 +303,7 @@ goto noproxy; } - /* Prepare protocol string to compare with. */ - _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); - - nr_elems = createProxyList(win_proxy, pproto, &head); + nr_elems = createProxyList(win_proxy, lpProto, &head); if (nr_elems != 0 && head != NULL) { int index = 0; proxy_array = (*env)->NewObjectArray(env, nr_elems, proxy_class, NULL); -Chris. P.S. I will take a look at the latest webrev. On 30/01/17 15:31, Zeller, Arno wrote: > Hi Chris, > > thanks for your comments! I adjusted the change to contain your suggestions and slightly modified > src/java.base/share/classes/java/net/doc-files/net-properties.html to refer to macOS . > Also found some missing adjustments of the copyright year myself... > >> Some smaller comments and observations ( I'm still reviewing and testing ): > ... >> 2) unix/native/libnet/DefaultProxySelector.c >> >> You have changes to make g_strv_length available, but then >> count the proxies in the list manually. Maybe just use >> g_strv_length. > Removed reference to g_strv_length - I simply forgot to delete it after changing my code to iterate over the list. > >> Nit: L 167 / 358 parameter indentation > Fixed. > >> 3) windows/native/libnet/DefaultProxySelector.c >> >> The HINTERNET session could be set lazily, for the case >> where there are no auto proxy settings. Not sure if it >> worth it though. > I would like to keep the current approach because it avoids the need of locking to ensure that the initialization is > done only by one thread. > >> The indentation of the main body of XXX_getSystemProxies >> could be reduced a little if: >> if (WinHttpGetIEProxyConfigForCurrentUser(&ie_proxy_config) == FALSE) >> return NULL; > Done. > >> 4) macosx/native/libnet/DefaultProxySelector.c >> >> The indentation of the main body of XXX_getSystemProxies >> could be reduced a little if: >> proxyDicRef = CFNetworkCopySystemProxySettings(); >> if (proxyDicRef == NULL) >> return NULL; > Done. > > >> 5) I personally prefer the code of the old createProxy. Was there >> specific reason why you changed it? > Sorry for this - another leftover from a former change. I reverted back to the original. > >> 6) Can you generally check the line lengths in all files, and try >> where possible to keep it below 100, e.g. some comments could >> easily be wrapped. > Done. > >> 7) I would like to add jtreg tags to test/java/net/ProxySelector/ >> SystemProxies.java to have it run in any automated test systems. >> There would be no failure mode of this test, as it requires >> manually inspecting the output, but it would at least give some >> coverage to this new code. Something like: >> /* >> * @test >> * @bug 8170868 >> * @summary Basic test to provide some coverage of system proxy code. >> Will >> * always pass. Should be run manually for specific systems to inspect >> output. >> * @run/othervm -Djava.net.useSystemProxies=true SystemProxies >> */ > Done. > > The new webrev can be found at: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.4/ > > Best regards, > Arno > From arno.zeller at sap.com Tue Jan 31 09:14:42 2017 From: arno.zeller at sap.com (Zeller, Arno) Date: Tue, 31 Jan 2017 09:14:42 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> Message-ID: Hi Chris, thanks a lot - I did not see this case in my tests. I added your change to my new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8170868.5/ Best regards, Arno >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Montag, 30. Januar 2017 17:14 >To: Zeller, Arno >Cc: net-dev at openjdk.java.net >Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >on Windows, MacOS and Gnome > >Arno, > >I found an issue on Windows when proxies are specified per-protocol, i.e. >they are returned with their optional scheme set. I believe that the scheme >should be checked, at least without this change FTP proxies were being >returned for HTTP URL's, on my machine. > >$ hg -R jdk diff >diff -r 07e07fecf383 >src/java.base/windows/native/libnet/DefaultProxySelector.c >--- a/src/java.base/windows/native/libnet/DefaultProxySelector.c >Mon Jan 30 14:09:14 2017 +0000 >+++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c >Mon Jan 30 16:09:23 2017 +0000 >@@ -99,6 +99,7 @@ > * Returns the size of the array as int. > */ > static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, >list_item **head) { >+ static const wchar_t separators[] = L"\t\r\n ;"; > list_item *current = NULL; > int nr_elems = 0; > wchar_t *context = NULL; >@@ -109,13 +110,26 @@ > * The proxy server list contains one or more of the following strings >separated by semicolons or whitespace. > * ([=]["://"][":"]) > */ >- current_proxy = wcstok_s(win_proxy, L"; ", &context); >- while (current_proxy != NULL) { >+ current_proxy = wcstok_s(win_proxy, separators, &context); >+ while (current_proxy != NULL) { > LPWSTR pport; > LPWSTR phost; > int portVal = 0; > wchar_t *next_proxy = NULL; > list_item *proxy = NULL; >+ wchar_t* pos = NULL; >+ >+ /* Filter based on the scheme, if there is one */ >+ pos = wcschr(current_proxy, L'='); >+ if (pos) { >+ *pos = L'\0'; >+ if (wcscmp(current_proxy, pproto) != 0) { >+ current_proxy = wcstok_s(NULL, separators, &context); >+ continue; >+ } >+ current_proxy = pos + 1; >+ } > > /* Let's check for a scheme and ignore it. */ > if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ -152,7 +166,7 >@@ > } > } > /* goto next proxy if available... */ >- current_proxy = wcstok_s(NULL, L"; ", &context); >+ current_proxy = wcstok_s(NULL, separators, &context); > } > return nr_elems; > } >@@ -268,7 +282,6 @@ > if (win_proxy != NULL) { > wchar_t *context = NULL; > int defport = 0; >- WCHAR pproto[MAX_STR_LEN]; > int nr_elems = 0; > > /** >@@ -290,10 +303,7 @@ > goto noproxy; > } > >- /* Prepare protocol string to compare with. */ >- _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); >- >- nr_elems = createProxyList(win_proxy, pproto, &head); >+ nr_elems = createProxyList(win_proxy, lpProto, &head); > if (nr_elems != 0 && head != NULL) { > int index = 0; > proxy_array = (*env)->NewObjectArray(env, nr_elems, proxy_class, >NULL); > >-Chris. > >P.S. I will take a look at the latest webrev. > From chris.hegarty at oracle.com Tue Jan 31 11:47:22 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 31 Jan 2017 11:47:22 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> Message-ID: Arno, Thanks for doing this, and your patience so far. One more final round of comments from me. Mostly minor. I?ve put them in the form of a webrev so you can easily view and import them, if you agree. http://cr.openjdk.java.net/~chegar/8170868_additional/ 1) A few comment rewordings and formatting suggestions. 2) I see duplicate DIRECT, and a few specific proxies, in my testing. Maybe my environment or PAC file is returning duplicate entries. I suggest that, at the java-level, we filter out duplicates while preserving ordering. ( see above webrev ) 3) We do not use asserts in core libraries. So I replaced the usage with an early return NULL ( no proxy ). At a later stage we could throw an exception or something, but probably not all that interesting. I have run this change ( along with my additional suggestions ) through our internal build and test system. No surprises. -Chris. > On 31 Jan 2017, at 09:14, Zeller, Arno wrote: > > Hi Chris, > > thanks a lot - I did not see this case in my tests. I added your change to my new webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.5/ > > > Best regards, > Arno > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Montag, 30. Januar 2017 17:14 >> To: Zeller, Arno >> Cc: net-dev at openjdk.java.net >> Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >> on Windows, MacOS and Gnome >> >> Arno, >> >> I found an issue on Windows when proxies are specified per-protocol, i.e. >> they are returned with their optional scheme set. I believe that the scheme >> should be checked, at least without this change FTP proxies were being >> returned for HTTP URL's, on my machine. >> >> $ hg -R jdk diff >> diff -r 07e07fecf383 >> src/java.base/windows/native/libnet/DefaultProxySelector.c >> --- a/src/java.base/windows/native/libnet/DefaultProxySelector.c >> Mon Jan 30 14:09:14 2017 +0000 >> +++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c >> Mon Jan 30 16:09:23 2017 +0000 >> @@ -99,6 +99,7 @@ >> * Returns the size of the array as int. >> */ >> static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, >> list_item **head) { >> + static const wchar_t separators[] = L"\t\r\n ;"; >> list_item *current = NULL; >> int nr_elems = 0; >> wchar_t *context = NULL; >> @@ -109,13 +110,26 @@ >> * The proxy server list contains one or more of the following strings >> separated by semicolons or whitespace. >> * ([=]["://"][":"]) >> */ >> - current_proxy = wcstok_s(win_proxy, L"; ", &context); >> - while (current_proxy != NULL) { >> + current_proxy = wcstok_s(win_proxy, separators, &context); >> + while (current_proxy != NULL) { >> LPWSTR pport; >> LPWSTR phost; >> int portVal = 0; >> wchar_t *next_proxy = NULL; >> list_item *proxy = NULL; >> + wchar_t* pos = NULL; >> + >> + /* Filter based on the scheme, if there is one */ >> + pos = wcschr(current_proxy, L'='); >> + if (pos) { >> + *pos = L'\0'; >> + if (wcscmp(current_proxy, pproto) != 0) { >> + current_proxy = wcstok_s(NULL, separators, &context); >> + continue; >> + } >> + current_proxy = pos + 1; >> + } >> >> /* Let's check for a scheme and ignore it. */ >> if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ -152,7 +166,7 >> @@ >> } >> } >> /* goto next proxy if available... */ >> - current_proxy = wcstok_s(NULL, L"; ", &context); >> + current_proxy = wcstok_s(NULL, separators, &context); >> } >> return nr_elems; >> } >> @@ -268,7 +282,6 @@ >> if (win_proxy != NULL) { >> wchar_t *context = NULL; >> int defport = 0; >> - WCHAR pproto[MAX_STR_LEN]; >> int nr_elems = 0; >> >> /** >> @@ -290,10 +303,7 @@ >> goto noproxy; >> } >> >> - /* Prepare protocol string to compare with. */ >> - _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); >> - >> - nr_elems = createProxyList(win_proxy, pproto, &head); >> + nr_elems = createProxyList(win_proxy, lpProto, &head); >> if (nr_elems != 0 && head != NULL) { >> int index = 0; >> proxy_array = (*env)->NewObjectArray(env, nr_elems, proxy_class, >> NULL); >> >> -Chris. >> >> P.S. I will take a look at the latest webrev. >> From arno.zeller at sap.com Tue Jan 31 19:14:20 2017 From: arno.zeller at sap.com (Zeller, Arno) Date: Tue, 31 Jan 2017 19:14:20 +0000 Subject: RFR:8170868: DefaultProxySelector should use system defaults on Windows, MacOS and Gnome In-Reply-To: References: <76e26ae6-dac6-5dd0-fc7d-6466bcbb084b@oracle.com> <8d0ff2a31d2242d89abad104ac9d8a07@DEROTE13DE10.global.corp.sap> <4453986b-e8d9-e045-d282-eca878982cca@oracle.com> <81525c687eeb410ba72060e4c336cca9@DEROTE13DE10.global.corp.sap> <2A66AE32-7A99-40B9-8576-6E14571E6622@oracle.com> <347b81bb-abf1-b084-3caa-38bced201b03@oracle.com> <436f383c-0feb-67b4-267f-ce4f005e8868@oracle.com> Message-ID: <2fdab8ff784d4a0ba394f464fa53c8a0@DEROTE13DE06.global.corp.sap> Hi Chris, thanks for all the improvements. I imported your webrev and prepared another webrev: http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ I have seen the multiple DIRECTs myself during testing and I think filtering on the java side is a very elegant solution. Thanks for this! Best regards, Arno >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Dienstag, 31. Januar 2017 12:47 >To: Zeller, Arno >Cc: net-dev at openjdk.java.net >Subject: Re: RFR:8170868: DefaultProxySelector should use system defaults >on Windows, MacOS and Gnome > >Arno, > >Thanks for doing this, and your patience so far. One more final round of >comments from me. Mostly minor. I?ve put them in the form of a webrev so >you can easily view and import them, if you agree. > > http://cr.openjdk.java.net/~chegar/8170868_additional/ > >1) A few comment rewordings and formatting suggestions. > >2) I see duplicate DIRECT, and a few specific proxies, in my > testing. Maybe my environment or PAC file is returning > duplicate entries. I suggest that, at the java-level, we filter > out duplicates while preserving ordering. ( see above webrev ) > >3) We do not use asserts in core libraries. So I replaced the usage > with an early return NULL ( no proxy ). At a later stage we could > throw an exception or something, but probably not all that > interesting. > >I have run this change ( along with my additional suggestions ) through our >internal build and test system. No surprises. > >-Chris. > >> On 31 Jan 2017, at 09:14, Zeller, Arno wrote: >> >> Hi Chris, >> >> thanks a lot - I did not see this case in my tests. I added your change to my >new webrev: >> http://cr.openjdk.java.net/~clanger/webrevs/8170868.5/ >> >> >> Best regards, >> Arno >> >>> -----Original Message----- >>> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >>> Sent: Montag, 30. Januar 2017 17:14 >>> To: Zeller, Arno >>> Cc: net-dev at openjdk.java.net >>> Subject: Re: RFR:8170868: DefaultProxySelector should use system >>> defaults on Windows, MacOS and Gnome >>> >>> Arno, >>> >>> I found an issue on Windows when proxies are specified per-protocol, i.e. >>> they are returned with their optional scheme set. I believe that the >>> scheme should be checked, at least without this change FTP proxies >>> were being returned for HTTP URL's, on my machine. >>> >>> $ hg -R jdk diff >>> diff -r 07e07fecf383 >>> src/java.base/windows/native/libnet/DefaultProxySelector.c >>> --- a/src/java.base/windows/native/libnet/DefaultProxySelector.c >>> Mon Jan 30 14:09:14 2017 +0000 >>> +++ b/src/java.base/windows/native/libnet/DefaultProxySelector.c >>> Mon Jan 30 16:09:23 2017 +0000 >>> @@ -99,6 +99,7 @@ >>> * Returns the size of the array as int. >>> */ >>> static int createProxyList(LPWSTR win_proxy, const WCHAR *pproto, >>> list_item **head) { >>> + static const wchar_t separators[] = L"\t\r\n ;"; >>> list_item *current = NULL; >>> int nr_elems = 0; >>> wchar_t *context = NULL; >>> @@ -109,13 +110,26 @@ >>> * The proxy server list contains one or more of the following >>> strings separated by semicolons or whitespace. >>> * ([=]["://"][":"]) >>> */ >>> - current_proxy = wcstok_s(win_proxy, L"; ", &context); >>> - while (current_proxy != NULL) { >>> + current_proxy = wcstok_s(win_proxy, separators, &context); >>> + while (current_proxy != NULL) { >>> LPWSTR pport; >>> LPWSTR phost; >>> int portVal = 0; >>> wchar_t *next_proxy = NULL; >>> list_item *proxy = NULL; >>> + wchar_t* pos = NULL; >>> + >>> + /* Filter based on the scheme, if there is one */ >>> + pos = wcschr(current_proxy, L'='); >>> + if (pos) { >>> + *pos = L'\0'; >>> + if (wcscmp(current_proxy, pproto) != 0) { >>> + current_proxy = wcstok_s(NULL, separators, &context); >>> + continue; >>> + } >>> + current_proxy = pos + 1; >>> + } >>> >>> /* Let's check for a scheme and ignore it. */ >>> if ((phost = wcsstr(current_proxy, L"://")) != NULL) { @@ >>> -152,7 +166,7 @@ >>> } >>> } >>> /* goto next proxy if available... */ >>> - current_proxy = wcstok_s(NULL, L"; ", &context); >>> + current_proxy = wcstok_s(NULL, separators, &context); >>> } >>> return nr_elems; >>> } >>> @@ -268,7 +282,6 @@ >>> if (win_proxy != NULL) { >>> wchar_t *context = NULL; >>> int defport = 0; >>> - WCHAR pproto[MAX_STR_LEN]; >>> int nr_elems = 0; >>> >>> /** >>> @@ -290,10 +303,7 @@ >>> goto noproxy; >>> } >>> >>> - /* Prepare protocol string to compare with. */ >>> - _snwprintf(pproto, sizeof(pproto), L"%s=", lpProto); >>> - >>> - nr_elems = createProxyList(win_proxy, pproto, &head); >>> + nr_elems = createProxyList(win_proxy, lpProto, &head); >>> if (nr_elems != 0 && head != NULL) { >>> int index = 0; >>> proxy_array = (*env)->NewObjectArray(env, nr_elems, >>> proxy_class, NULL); >>> >>> -Chris. >>> >>> P.S. I will take a look at the latest webrev. >>> From daniel.fuchs at oracle.com Tue Jan 31 19:18:25 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Jan 2017 19:18:25 +0000 Subject: RFR(S): 8173475 : java/net/HttpURLConnection/SetAuthenticator tests have undeclared dependency on java.logging module In-Reply-To: <96807ec3-339d-6001-7779-ca2f0bef9a7f@oracle.com> References: <96807ec3-339d-6001-7779-ca2f0bef9a7f@oracle.com> Message-ID: +1 best regards, -- daniel On 27/01/17 12:43, Sergei Kovalev wrote: > Hi All, > > Please review a small fix for tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8173475 > WebRev: http://cr.openjdk.java.net/~skovalev/8173475/webrev.00/ > > Issue: Two tests fail in case of usage '--limit-module' command line > option. > Root cause: One of the files HTTPTest.java has dependency on > java.logging module. Second tests HTTPSetAuthenticatorTest.java extends > first one. Therefore we need to add dependency declaration to the both > tests. >