From sergei.kovalev at oracle.com Mon Oct 3 10:08:13 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 13:08:13 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> Message-ID: <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> Resending this for review 27.09.16 18:44, Sergei Kovalev wrote: > Hi team, > > Could you please review small fix for regression tests. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166791 > WebRev: http://cr.openjdk.java.net/~skovalev/8166791/webrev.00/ > > Issue: Severl network related tests failed in case of using > "--limit-modules java.base" command line option. > > The test java/net/httpclient/http2/ErrorTest.java should declare > dependencies on 'jdk.security.auth' module. > > java/net/httpclient/security/Driver.java should depend oh > 'java.httpclient' and 'jdk.httpserver'. > > java/net/spi/URLStreamHandlerProvider/Basic.java and > sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java have > declaration of dependency on 'java.compiler' but should be > 'jdk.compiler'. > > From the test java/net/httpclient/http2/HpackDriver.java extracted one > part that depends on 'jdk.localedata': > java/net/httpclient/http2/HpackDriverHeaderTable.java because other > part don't have any extra dependencies and could be executed in > general case. > -- With best regards, Sergei From chris.hegarty at oracle.com Mon Oct 3 13:05:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 3 Oct 2016 14:05:03 +0100 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> Message-ID: Sergei, On 03/10/16 11:08, Sergei Kovalev wrote: > Resending this for review > > > 27.09.16 18:44, Sergei Kovalev wrote: >> Hi team, >> >> Could you please review small fix for regression tests. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8166791 >> WebRev: http://cr.openjdk.java.net/~skovalev/8166791/webrev.00/ >> Issue: Severl network related tests failed in case of using >> "--limit-modules java.base" command line option. >> >> The test java/net/httpclient/http2/ErrorTest.java should declare >> dependencies on 'jdk.security.auth' module. I cannot find the reason why you think this module needs jdk.security.auth, can you please explain. >> java/net/httpclient/security/Driver.java should depend oh >> 'java.httpclient' and 'jdk.httpserver'. >> >> java/net/spi/URLStreamHandlerProvider/Basic.java and >> sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java have >> declaration of dependency on 'java.compiler' but should be >> 'jdk.compiler'. They should require both java.compiler and jdk.compiler, no? >> From the test java/net/httpclient/http2/HpackDriver.java extracted one >> part that depends on 'jdk.localedata': >> java/net/httpclient/http2/HpackDriverHeaderTable.java because other >> part don't have any extra dependencies and could be executed in >> general case. -Chris. From sergei.kovalev at oracle.com Mon Oct 3 13:33:39 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 16:33:39 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> Message-ID: Hi Chris, Thank you for looking this. 03.10.16 16:05, Chris Hegarty wrote: > Sergei, > > On 03/10/16 11:08, Sergei Kovalev wrote: >> Resending this for review >> >> >> 27.09.16 18:44, Sergei Kovalev wrote: >>> Hi team, >>> >>> Could you please review small fix for regression tests. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8166791 >>> WebRev: http://cr.openjdk.java.net/~skovalev/8166791/webrev.00/ > >>> Issue: Severl network related tests failed in case of using >>> "--limit-modules java.base" command line option. >>> >>> The test java/net/httpclient/http2/ErrorTest.java should declare >>> dependencies on 'jdk.security.auth' module. > > I cannot find the reason why you think this module needs > jdk.security.auth, can you please explain. SSL engin requires security provider. Its implementation located in jdk.security.auth. In case no jdk module added we getting an exception: test ErrorTest.test(): failure java.lang.IllegalArgumentException: Cannot support TLS_KRB5_WITH_3DES_EDE_CBC_SHA with currently installed providers at sun.security.ssl.CipherSuiteList.(java.base at 9-ea/CipherSuiteList.java:81) at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(java.base at 9-ea/SSLEngineImpl.java:2087) at javax.net.ssl.SSLEngine.setSSLParameters(java.base at 9-ea/SSLEngine.java:1269) at sun.security.ssl.SSLEngineImpl.setSSLParameters(java.base at 9-ea/SSLEngineImpl.java:2166) ... > >>> java/net/httpclient/security/Driver.java should depend oh >>> 'java.httpclient' and 'jdk.httpserver'. >>> >>> java/net/spi/URLStreamHandlerProvider/Basic.java and >>> sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java have >>> declaration of dependency on 'java.compiler' but should be >>> 'jdk.compiler'. > > They should require both java.compiler and jdk.compiler, no? You are right. The tests requires java.compiler for compilation and jdk.compiler for execution. I've done appropriate changes. Please take a look at: http://cr.openjdk.java.net/~skovalev/8166791/webrev.01/ > >>> From the test java/net/httpclient/http2/HpackDriver.java extracted one >>> part that depends on 'jdk.localedata': >>> java/net/httpclient/http2/HpackDriverHeaderTable.java because other >>> part don't have any extra dependencies and could be executed in >>> general case. > > -Chris. > -- With best regards, Sergei From Alan.Bateman at oracle.com Mon Oct 3 13:36:46 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Oct 2016 14:36:46 +0100 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> Message-ID: On 03/10/2016 14:33, Sergei Kovalev wrote: > > SSL engin requires security provider. Its implementation located in > jdk.security.auth. In case no jdk module added we getting an exception: > > test ErrorTest.test(): failure > java.lang.IllegalArgumentException: Cannot support > TLS_KRB5_WITH_3DES_EDE_CBC_SHA with currently installed providers > at > sun.security.ssl.CipherSuiteList.(java.base at 9-ea/CipherSuiteList.java:81) > at > sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(java.base at 9-ea/SSLEngineImpl.java:2087) > at > javax.net.ssl.SSLEngine.setSSLParameters(java.base at 9-ea/SSLEngine.java:1269) > at > sun.security.ssl.SSLEngineImpl.setSSLParameters(java.base at 9-ea/SSLEngineImpl.java:2166) The Kerberos ciphers are in java.security.jgss so that might be what you need here. -Alan From sergei.kovalev at oracle.com Mon Oct 3 13:43:37 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 16:43:37 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> Message-ID: <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> Fixed http://cr.openjdk.java.net/~skovalev/8166791/webrev.02/ 03.10.16 16:36, Alan Bateman wrote: > > > On 03/10/2016 14:33, Sergei Kovalev wrote: >> >> SSL engin requires security provider. Its implementation located in >> jdk.security.auth. In case no jdk module added we getting an exception: >> >> test ErrorTest.test(): failure >> java.lang.IllegalArgumentException: Cannot support >> TLS_KRB5_WITH_3DES_EDE_CBC_SHA with currently installed providers >> at >> sun.security.ssl.CipherSuiteList.(java.base at 9-ea/CipherSuiteList.java:81) >> at >> sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(java.base at 9-ea/SSLEngineImpl.java:2087) >> at >> javax.net.ssl.SSLEngine.setSSLParameters(java.base at 9-ea/SSLEngine.java:1269) >> at >> sun.security.ssl.SSLEngineImpl.setSSLParameters(java.base at 9-ea/SSLEngineImpl.java:2166) > The Kerberos ciphers are in java.security.jgss so that might be what > you need here. > > -Alan -- With best regards, Sergei From chris.hegarty at oracle.com Mon Oct 3 13:59:57 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 3 Oct 2016 14:59:57 +0100 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> Message-ID: <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> On 03/10/16 14:43, Sergei Kovalev wrote: > Fixed > > http://cr.openjdk.java.net/~skovalev/8166791/webrev.02/ java.compiler already exports javax.tools so no need for the explicit export in the @modules tag. Otherwise this is fine. -Chris. > > 03.10.16 16:36, Alan Bateman wrote: >> >> >> On 03/10/2016 14:33, Sergei Kovalev wrote: >>> >>> SSL engin requires security provider. Its implementation located in >>> jdk.security.auth. In case no jdk module added we getting an exception: >>> >>> test ErrorTest.test(): failure >>> java.lang.IllegalArgumentException: Cannot support >>> TLS_KRB5_WITH_3DES_EDE_CBC_SHA with currently installed providers >>> at >>> sun.security.ssl.CipherSuiteList.(java.base at 9-ea/CipherSuiteList.java:81) >>> >>> at >>> sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(java.base at 9-ea/SSLEngineImpl.java:2087) >>> >>> at >>> javax.net.ssl.SSLEngine.setSSLParameters(java.base at 9-ea/SSLEngine.java:1269) >>> >>> at >>> sun.security.ssl.SSLEngineImpl.setSSLParameters(java.base at 9-ea/SSLEngineImpl.java:2166) >>> >> The Kerberos ciphers are in java.security.jgss so that might be what >> you need here. >> >> -Alan > From sergei.kovalev at oracle.com Mon Oct 3 14:05:21 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 17:05:21 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> Message-ID: <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> Such notation (module/package) helps to jtreg to understand that the module required on compilation stage. Jtreg adding "--add-exports module/package=ALL-UNNAMED" for each record of this type. In our case id adds a string: --add-exports java.compiler/javax.tools=ALL-UNNAMED. -- With best regards, Sergei 03.10.16 16:59, Chris Hegarty wrote: > On 03/10/16 14:43, Sergei Kovalev wrote: >> Fixed >> >> http://cr.openjdk.java.net/~skovalev/8166791/webrev.02/ > > java.compiler already exports javax.tools so no need for the > explicit export in the @modules tag. Otherwise this is fine. > > -Chris. > >> >> 03.10.16 16:36, Alan Bateman wrote: >>> >>> >>> On 03/10/2016 14:33, Sergei Kovalev wrote: >>>> >>>> SSL engin requires security provider. Its implementation located in >>>> jdk.security.auth. In case no jdk module added we getting an >>>> exception: >>>> >>>> test ErrorTest.test(): failure >>>> java.lang.IllegalArgumentException: Cannot support >>>> TLS_KRB5_WITH_3DES_EDE_CBC_SHA with currently installed providers >>>> at >>>> sun.security.ssl.CipherSuiteList.(java.base at 9-ea/CipherSuiteList.java:81) >>>> >>>> >>>> at >>>> sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(java.base at 9-ea/SSLEngineImpl.java:2087) >>>> >>>> >>>> at >>>> javax.net.ssl.SSLEngine.setSSLParameters(java.base at 9-ea/SSLEngine.java:1269) >>>> >>>> >>>> at >>>> sun.security.ssl.SSLEngineImpl.setSSLParameters(java.base at 9-ea/SSLEngineImpl.java:2166) >>>> >>>> >>> The Kerberos ciphers are in java.security.jgss so that might be what >>> you need here. >>> >>> -Alan >> From Alan.Bateman at oracle.com Mon Oct 3 14:07:54 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Oct 2016 15:07:54 +0100 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> Message-ID: <15867088-6a45-49ba-7d26-10b0b2d6ba1c@oracle.com> On 03/10/2016 15:05, Sergei Kovalev wrote: > Such notation (module/package) helps to jtreg to understand that the > module required on compilation stage. Jtreg adding "--add-exports > module/package=ALL-UNNAMED" for each record of this type. In our case > id adds a string: --add-exports java.compiler/javax.tools=ALL-UNNAMED. > Chris is right, there is no need for "/javax.tools" here. -Alan From sergei.kovalev at oracle.com Mon Oct 3 14:19:59 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 17:19:59 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <15867088-6a45-49ba-7d26-10b0b2d6ba1c@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> <15867088-6a45-49ba-7d26-10b0b2d6ba1c@oracle.com> Message-ID: <2ddd71ef-d169-0d2a-4ad6-87cbe49cf3ed@oracle.com> Changed http://cr.openjdk.java.net/~skovalev/8166791/webrev.03/ 03.10.16 17:07, Alan Bateman wrote: > > > On 03/10/2016 15:05, Sergei Kovalev wrote: >> Such notation (module/package) helps to jtreg to understand that the >> module required on compilation stage. Jtreg adding "--add-exports >> module/package=ALL-UNNAMED" for each record of this type. In our case >> id adds a string: --add-exports java.compiler/javax.tools=ALL-UNNAMED. >> > Chris is right, there is no need for "/javax.tools" here. > > -Alan > -- With best regards, Sergei From chris.hegarty at oracle.com Mon Oct 3 14:22:34 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 3 Oct 2016 15:22:34 +0100 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: <2ddd71ef-d169-0d2a-4ad6-87cbe49cf3ed@oracle.com> References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> <15867088-6a45-49ba-7d26-10b0b2d6ba1c@oracle.com> <2ddd71ef-d169-0d2a-4ad6-87cbe49cf3ed@oracle.com> Message-ID: On 03/10/16 15:19, Sergei Kovalev wrote: > Changed > > http://cr.openjdk.java.net/~skovalev/8166791/webrev.03/ This looks fine. Reviewed. No need to generate the webrev, but can you please check that you list the java.* modules before the jdk.* ones. Thanks, -Chris. > 03.10.16 17:07, Alan Bateman wrote: >> >> >> On 03/10/2016 15:05, Sergei Kovalev wrote: >>> Such notation (module/package) helps to jtreg to understand that the >>> module required on compilation stage. Jtreg adding "--add-exports >>> module/package=ALL-UNNAMED" for each record of this type. In our case >>> id adds a string: --add-exports java.compiler/javax.tools=ALL-UNNAMED. >>> >> Chris is right, there is no need for "/javax.tools" here. >> >> -Alan >> > From sergei.kovalev at oracle.com Mon Oct 3 14:24:18 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 3 Oct 2016 17:24:18 +0300 Subject: RFR(s): 8166791: Fix module dependencies for networking component tests In-Reply-To: References: <42a7caf2-528f-2f0d-45ac-5ac6adf571e4@oracle.com> <56d9cf24-edb2-13a8-d96a-03109350214e@oracle.com> <00e02522-0326-abd0-c924-4c4ec4c6dbd8@oracle.com> <15e42e4f-f799-7f8b-4b81-b78a16455ea6@oracle.com> <8390168a-bc4e-da76-5f60-6c95a56b9d48@oracle.com> <15867088-6a45-49ba-7d26-10b0b2d6ba1c@oracle.com> <2ddd71ef-d169-0d2a-4ad6-87cbe49cf3ed@oracle.com> Message-ID: Ok. Will do 03.10.16 17:22, Chris Hegarty wrote: > On 03/10/16 15:19, Sergei Kovalev wrote: >> Changed >> >> http://cr.openjdk.java.net/~skovalev/8166791/webrev.03/ > > This looks fine. Reviewed. > > No need to generate the webrev, but can you please check that you list > the java.* modules before the jdk.* ones. > > Thanks, > -Chris. -- With best regards, Sergei -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Oct 4 08:50:52 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 Oct 2016 08:50:52 +0000 Subject: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false) In-Reply-To: <3D441FDE-621D-422D-8826-5A978D39FC38@oracle.com> References: <9e973688-b1cb-cf1b-98c8-65f3f13a8fe5@oracle.com> <06ac9dd0-f7a7-f2b7-cff4-629eb860a5bc@oracle.com> <1288b656-37e2-c5ac-1e38-9c1ddb552485@oracle.com> <56ef2531-cbab-9caf-cc84-3a82c7ee5c69@oracle.com> <0db2cae9-db2f-723e-bf5e-4ecadae94fce@oracle.com> <2a451385-ce41-dd15-a21c-b495f805a347@oracle.com> <850bd3be-1917-a697-8298-c26da68a0065@oracle.com> <9ACD5B67AAC5594CB6268234CF29CF9AA5137216@ORSMSX113.amr.corp.intel.com> <2AFB39BF-AB16-4DFA-BAF8-02FE1E84C0FA@oracle.com> <3D441FDE-621D-422D-8826-5A978D39FC38@oracle.com> Message-ID: <9273b788c92f417b877354ec09b47dac@DEWDFE13DE11.global.corp.sap> +1 ... Looks good to me > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris > Hegarty > Sent: Donnerstag, 29. September 2016 10:21 > To: Vyom Tewari > Cc: Kharbas, Kishor ; Viswanathan, Sandhya > ; Aundhe, Shirish > ; net-dev ; Kaczmarek, > Eric > Subject: Re: RFR 8153674: Expected SocketException not thrown when calling > bind() with setReuseAddress(false) > > > > On 29 Sep 2016, at 09:16, Vyom Tewari wrote: > > > > Hi All, > > > > Please find the latest > webrev(http://cr.openjdk.java.net/~vtewari/8153674/webrev0.1/index.html). I > had removed the SO_REUSEPORT & spec from constructor. > > Thank you Vyom, this looks good to me. > > -Chris. > > > Thanks, > > > > Vyom > > > > On Thursday 29 September 2016 01:38 AM, Chris Hegarty wrote: > >> Thank you Lucy, > >> > >> We?ll proceed with removing the setting of SO_REUSEPORT from the > >> MulticastSocket constructor and spec. > >> > >> -Chris. > >> > >>> On 28 Sep 2016, at 20:02, Lu, Yingqi wrote: > >>> > >>> Hi Vyom, > >>> > >>> Thank you very much checking with us. > >>> > >>> We agree that SO_RESUEADDR and SO_REUSEPORT behave the same way > for MulticastSocket. There is no need to check and enable SO_REUSEPORT for > this particular type of socket. SO_REUSEADDR is sufficient. > >>> > >>> Thanks, > >>> Lucy > >>> > >>> From: Vyom Tewari [mailto:vyom.tewari at oracle.com] > >>> Sent: Wednesday, September 28, 2016 1:26 AM > >>> To: Chris Hegarty ; Mark Sheppard > ; net-dev ; > Kaczmarek, Eric ; Viswanathan, Sandhya > ; Kharbas, Kishor > ; Aundhe, Shirish ; Lu, > Yingqi > >>> Subject: Re: RFR 8153674: Expected SocketException not thrown when > calling bind() with setReuseAddress(false) > >>> > >>> Hi All, > >>> > >>> I had off line discussion here at Oracle and we decided not to override > getReuseAddr/setReuseAddr for MulticastSocket. If user wants, he can set the > SO_REUSEPORT with "setOption" before bind. > >>> > >>> For MulticastSocket SO_REUSEADDR&SO_REUSEPORT are semantically > equivalent which means either option will be sufficient to indicate that the > address&port is reusable. So setting SO_REUSEPORT in constructor is really > necessary/required ? > >>> > >>> I am looking some comments on this from Intel people(they are in mail > chain) who did this original change, before we decide how we wants to proceed > on this issue. > >>> > >>> Thanks, > >>> > >>> Vyom > >>> > >>> > >>> On Wednesday 14 September 2016 08:47 PM, Chris Hegarty wrote: > >>> On 14/09/16 15:53, Mark Sheppard wrote: > >>> > >>> > >>> that's true wrt SO_REUSEPORT in MulticastSocket constructor. But the > >>> same could have been argued for the original > >>> invocation of setReuseAddress, by default , in the constructors, which > >>> is encapsulating, what pereceived as, common or defacto > >>> practice wrt applying SO_REUSEADDR on mcast sockets at the system > level. > >>> As I understand it, it is generally perceived that SO_REUSEADDR and > >>> SO_REUSEPORT are semantically equivalent for multicast sockets. > >>> As such, I think in the case of MulticastSocket, the fact that the > >>> setRuseAddress() is called in the constructor, it is appropriate > >>> to set SO_REUSEPORT also when it exists in the OS. > >>> > >>> I take your point on the semantics of setReuseAddress in DatagramSocket > >>> as per its spec. The spec does allude to MulticastSocket. > >>> As such, the current proposal's changes just lack the appropriate > >>> javadoc to describe its behavior, and its additional functionality of > >>> setting SO_REUSEPORT. > >>> It is not necessary that overridden method should mirror the semantics > >>> of the base class method. > >>> If it is accepted that it is generally perceived that SO_REUSEADDR and > >>> SO_REUSEPORT are semantically equivalent for multicast sockets, > >>> then it seems appropriate that an overriding setReuseAddress(..) method > >>> in MulticastSocket can reflect this. > >>> > >>> That sounds reasonable. > >>> > >>> -Chris. > >>> > >>> > >>> regards > >>> Mark > >>> > >>> > >>> > >>> On 14/09/2016 14:58, Chris Hegarty wrote: > >>> > >>> One additional remark. > >>> > >>> Was it appropriate to update the legacy MC constructors > >>> to set the new JDK 9 SO_REUSEPORT in the first place? > >>> This can be achievable, opt-in from new code, by creating > >>> an unbound MS, setting the option, then binding. > >>> > >>> -Chris. > >>> > >>> On 14/09/16 14:47, Chris Hegarty wrote: > >>> > >>> Mark, > >>> > >>> On 14/09/16 14:22, Mark Sheppard wrote: > >>> > >>> > >>> Hi Chris, > >>> I don't fully understand your objections to the approach taken. > >>> Is there a compatibility issue with the addition of the additional > >>> methods to MulticastSocket? > >>> > >>> The concern is with setReuseAddress performing an operation that > >>> is not clear from the method specification, e.g. from setReuseAddress() > >>> > >>> * Enable/disable the SO_REUSEADDR socket option. > >>> > >>> This is no longer accurate. The proposed changes would affect > >>> SO_REUSEPORT too. > >>> > >>> > >>> I don't see Datagram.setReuseAddress(...) handling the SO_REUSEPORT > >>> option, this has to be done explicitly via setOption at this level of > >>> abstraction. > >>> > >>> Yes, it is a bit odd, but these are legacy classes. I am not opposed > >>> to adding a new method for this, or something else. I just want to > >>> avoid future issues and confusion when setReuseAddress is called and > >>> then it is noticed that, the somewhat orthogonal option, SO_REUSEPORT's > >>> value has changed. setReuseAddress's spec is very clear about what it > >>> does. > >>> > >>> > >>> MulticastSocket is a subclass of DatagramSocket (that in itself is a > >>> questionable structuring), and as such > >>> has specialized behaviour, and part of that specialization is the > >>> setting of the setting SO_REUSEADDR and SO_REUSEPORT > >>> in its constructors, to enable address reuse semantics, prior to > >>> binding > >>> an address. > >>> > >>> Understood. Of course, the setting of SO_REUSEPORT is new in 9, > >>> hence the problem. > >>> > >>> > >>> As part of that specialization, it would seem appropriate that > >>> MulticastSocket manipulate the SO_REUSEPORT > >>> option in a consistent way. Adding an overridden setReuseAddress(...) > >>> method provides that consistency and > >>> encapsulates the specialized behaviour. > >>> > >>> I agree with the abstraction, just not that setReuseAddress should > >>> be used to achieve it. The name and spec of this method is so > >>> tied to SO_REUSEADDR. > >>> > >>> > >>> Is alternatively proposal to NOT do anything to MulticastSocket, BUT > >>> document clearly how to handle the failing scenario, that an > >>> MulticastSocket > >>> requires both setReuseAddress() and a setOption call to disable > >>> reuseaddress semantics on an unbound MulticastSocket ? > >>> > >>> That is one option, and the option that I was suggesting as a possible > >>> alternative. > >>> > >>> > >>> This then raises the question of why have a convenience method, such as > >>> setReuseAddress() in the first place, when it can be handled > >>> adequately via the setOption > >>> > >>> We are moving away from these option specific getter and setter > >>> methods, in favor of the more general get/setOption methods, as > >>> the latter are more adaptable. > >>> > >>> If setReuseAddress is to operate on more than SO_REUSEADDR, then > >>> its spec should be very clear about this. > >>> > >>> -Chris. > >>> > >>> > >>> > >>> regards > >>> Mark > >>> > >>> On 14/09/2016 13:34, Chris Hegarty wrote: > >>> > >>> Mark, > >>> > >>> On 14/09/16 13:23, Mark Sheppard wrote: > >>> > >>> > >>> Hi Chris, > >>> so are you accepting that it is correct to add the overridden > >>> methods in MulticastSocket and that these need > >>> appropriate javadoc ? > >>> > >>> I think we need these, but they should just call their super > >>> equivalents, i.e. no implicit setting of SO_REUSEPORT. They would > >>> exist solely as a place to locate guidance, or a note, that one > >>> will likely want to set SO_REUSEPORT too. > >>> > >>> > >>> or are you advocating pushing the handing of the SO_REUSEPORT into > >>> the > >>> base DatagramSocket class ? > >>> > >>> It is already there. I am not proposing to change this. > >>> > >>> > >>> It is not clear how your code changes fit in the proposed fix i.e. > >>> the > >>> explicit setting of the option to false? > >>> > >>> My proposal is an alternative. It is not related to the current > >>> webrev. > >>> > >>> > >>> With the current proposed changes then I think it would be > >>> sufficient to > >>> invoke setReuseAddress(true) in MulticastSocket constructors > >>> rather than > >>> > >>> // Enable SO_REUSEADDR before binding > >>> setReuseAddress > >>> dev>(*true*); > >>> > >>> > >>> > >>> > >>> // Enable SO_REUSEPORT if supported before binding > >>> *if* (supportedOptions > >>> dev/jdk/src/java.base/share/classes/java/net/MulticastSocket.java#supportedO > ptions>().contains > >>> > >>> > >>> > >>> dev>(StandardSocketOptions > >>> > >>> > >>> > >>> > 9-dev>.SO_REUSEPORT > >>> > >>> > >>> > >>> dev>)) > >>> > >>> > >>> { > >>> *this*.setOption > >>> dev>(StandardSocketOptions > >>> > >>> > >>> > >>> > 9-dev>.SO_REUSEPORT > >>> > >>> > >>> > >>> dev>, > >>> > >>> > >>> *true*); > >>> } > >>> > >>> > >>> as the overridden setReuseAddress takes care of SO_REUSEPORT > >>> > >>> Yes, this is what Vyom has proposed, in the webrev. > >>> > >>> I would like to explore an alternative, so see what it would look > >>> like. > >>> > >>> -Chris. > >>> > >>> > >>> > >>> regards > >>> Mark > >>> > >>> On 14/09/2016 11:43, Chris Hegarty wrote: > >>> > >>> Vyom, > >>> > >>> On 11/09/16 08:01, Vyom Tewari wrote: > >>> > >>> Hi All, > >>> > >>> Please review the below code change. > >>> > >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8153674 > >>> > >>> Webrev : > >>> http://cr.openjdk.java.net/~vtewari/8153674/webrev0.0/index.html > >>> > >>> > >>> > >>> This change override the "get/setReuseAddress" for MulticaseSocket > >>> and > >>> will abstract with both reuse attributes(SO_REUSEADDR & > >>> SO_REUSEPORT). > >>> > >>> This issue arises since the changes for 6432031 "Add support for > >>> SO_REUSEPORT" [1], which sets SO_REUSEPORT on MulticastSocket, if > >>> the available. So setting setReuseAddress(false) alone is no longer > >>> sufficient to disable address/port reuse, one must also set > >>> SO_REUSEPORT to false. > >>> > >>> I would be really nervous about changing set/getReuseAddress, > >>> without > >>> at least updating the javadoc to indicate that it is now, for MS, > >>> operating on two socket options. Although, I do have sympathy > >>> here since SO_REUSEPORT and SO_REUSEADDR are almost identical when > >>> dealing with multicasting. > >>> > >>> An alternative, maybe; Since the MS constructors document that > >>> SO_REUSEPORT will be set, where available, maybe a javadoc note > >>> on the set/getReuseAddress methods would be sufficient, that > >>> indicates that StandardSocketOptions#SO_REUSEPORT may also need > >>> to be set to have the desired effect? > >>> > >>> If so, then code would have to: > >>> > >>> setReuseAddress(false); > >>> > >>> if > >>> (supportedOptions().contains(StandardSocketOptions.SO_REUSEPORT)) > >>> this.setOption(StandardSocketOptions.SO_REUSEPORT, false); > >>> > >>> , but at least it is explicit. > >>> > >>> Q: not all MS constructors document that SO_REUSEPORT is set, but > >>> they should, right? This seems to have slipped past during 6432031 > >>> [1]. > >>> > >>> -Chris. > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-6432031 > >>> > >>> > >>> > >>> > >> > > From christoph.langer at sap.com Tue Oct 4 08:58:48 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 4 Oct 2016 08:58:48 +0000 Subject: Introduce IOException subclass for ECONNRESET In-Reply-To: <942a191e-f546-c80c-01f4-867c7e1f8a52@oracle.com> References: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com> <942a191e-f546-c80c-01f4-867c7e1f8a52@oracle.com> Message-ID: <1079e41871e7433baa4563338c2f2b82@DEWDFE13DE11.global.corp.sap> Hi, I think I would also support replacing sun.net.ConnectionResetException with a publicly available java.net.ConnectionResetException that subclasses java.net.SocketException. But, as Chris mentions. a usage example would be helpful. Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris > Hegarty > Sent: Montag, 12. September 2016 17:07 > To: Florian Weimer ; Norman Maurer > ; net-dev at openjdk.java.net > Subject: Re: Introduce IOException subclass for ECONNRESET > > On 12/09/16 14:50, Florian Weimer wrote: > > On 08/23/2016 09:40 AM, Norman Maurer wrote: > >> Hi all, > >> > >> I first asked this on nio-dev[0] but was asked to move this over to here: > >> > >> I wonder if it would be possible to add a new IOException sub-class > >> for ECONNRESET. Often you receive these errors if a remote peer closed > >> the connection and you try to read from it while using NIO. This is > >> very often not really something that concerns people and can just be > >> handled the same as a ?normal close?. > > So what are the other cases, where ECONNRESET may occur? What is > equivalent on non-Unix platforms, Windows for example? > > >> At the moment the only way to > >> detect this is to inspect the IOException message which is really > >> hacky. > > Do you have examples of code that does this today? > > >> I wonder if we could not add a special IOException sub-class > >> for this. Something like: > >> > >> ConnectionResetException extends IOException { > >> } > > > > Shouldn't it be a subclass of SocketException? > > I think it would have to be a subclass of SocketException too, for > compatibility at least, since that is the type that is thrown > today. > > sun.net.ConnectionResetException exists today, but I don't think > that it ever finds its way outside of the implementation. And is > of course not part of Java SE. > > -Chris. > From david.lloyd at redhat.com Tue Oct 4 12:52:06 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Tue, 4 Oct 2016 07:52:06 -0500 Subject: Introduce IOException subclass for ECONNRESET In-Reply-To: <1079e41871e7433baa4563338c2f2b82@DEWDFE13DE11.global.corp.sap> References: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com> <942a191e-f546-c80c-01f4-867c7e1f8a52@oracle.com> <1079e41871e7433baa4563338c2f2b82@DEWDFE13DE11.global.corp.sap> Message-ID: On 10/04/2016 03:58 AM, Langer, Christoph wrote: > Hi, > > I think I would also support replacing sun.net.ConnectionResetException with a publicly available java.net.ConnectionResetException that subclasses java.net.SocketException. But, as Chris mentions. a usage example would be helpful. At present you're going to be hard-pressed to find exiting code that detects a connection reset IOException. The reason is that, while you *can* search for "Connection reset by peer" in the exception message, that text varies by platform and, more importantly, by locale. So it is essentially impossible to detect reliably. But Norman's use case is dead on: a connection reset happens under common circumstances. In particular, when a TCP socket is closed by the peer before the peer has read all pending data, an RST is returned. This happens very often - when a peer process is terminated for example, or the peer encounters an unrelated exception and terminates the connection abruptly, both of which happen very, very commonly in networked applications. For servers the choice today is to fill the log with meaningless exception traces or lose potentially more serious problems (EIO for example is something that almost always indicates Bad Things). I also support this proposal. >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Chris >> Hegarty >> Sent: Montag, 12. September 2016 17:07 >> To: Florian Weimer ; Norman Maurer >> ; net-dev at openjdk.java.net >> Subject: Re: Introduce IOException subclass for ECONNRESET >> >> On 12/09/16 14:50, Florian Weimer wrote: >>> On 08/23/2016 09:40 AM, Norman Maurer wrote: >>>> Hi all, >>>> >>>> I first asked this on nio-dev[0] but was asked to move this over to here: >>>> >>>> I wonder if it would be possible to add a new IOException sub-class >>>> for ECONNRESET. Often you receive these errors if a remote peer closed >>>> the connection and you try to read from it while using NIO. This is >>>> very often not really something that concerns people and can just be >>>> handled the same as a ?normal close?. >> >> So what are the other cases, where ECONNRESET may occur? What is >> equivalent on non-Unix platforms, Windows for example? >> >> >> At the moment the only way to >>>> detect this is to inspect the IOException message which is really >>>> hacky. >> >> Do you have examples of code that does this today? >> >>>> I wonder if we could not add a special IOException sub-class >>>> for this. Something like: >>>> >>>> ConnectionResetException extends IOException { >>>> } >>> >>> Shouldn't it be a subclass of SocketException? >> >> I think it would have to be a subclass of SocketException too, for >> compatibility at least, since that is the type that is thrown >> today. >> >> sun.net.ConnectionResetException exists today, but I don't think >> that it ever finds its way outside of the implementation. And is >> of course not part of Java SE. >> >> -Chris. >> > -- - DML From chris.hegarty at oracle.com Wed Oct 5 08:58:27 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Oct 2016 09:58:27 +0100 Subject: Introduce IOException subclass for ECONNRESET In-Reply-To: References: <0456C96C-1FBA-4031-9845-54EC4D134A9B@googlemail.com> <942a191e-f546-c80c-01f4-867c7e1f8a52@oracle.com> <1079e41871e7433baa4563338c2f2b82@DEWDFE13DE11.global.corp.sap> Message-ID: I filed the following issue to track this: https://bugs.openjdk.java.net/browse/JDK-8167161 -Chris. On 04/10/16 13:52, David M. Lloyd wrote: > On 10/04/2016 03:58 AM, Langer, Christoph wrote: >> Hi, >> >> I think I would also support replacing >> sun.net.ConnectionResetException with a publicly available >> java.net.ConnectionResetException that subclasses >> java.net.SocketException. But, as Chris mentions. a usage example >> would be helpful. > > At present you're going to be hard-pressed to find exiting code that > detects a connection reset IOException. The reason is that, while you > *can* search for "Connection reset by peer" in the exception message, > that text varies by platform and, more importantly, by locale. So it is > essentially impossible to detect reliably. > > But Norman's use case is dead on: a connection reset happens under > common circumstances. In particular, when a TCP socket is closed by the > peer before the peer has read all pending data, an RST is returned. This > happens very often - when a peer process is terminated for example, or > the peer encounters an unrelated exception and terminates the connection > abruptly, both of which happen very, very commonly in networked > applications. For servers the choice today is to fill the log with > meaningless exception traces or lose potentially more serious problems > (EIO for example is something that almost always indicates Bad Things). > > I also support this proposal. > >>> -----Original Message----- >>> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of >>> Chris >>> Hegarty >>> Sent: Montag, 12. September 2016 17:07 >>> To: Florian Weimer ; Norman Maurer >>> ; net-dev at openjdk.java.net >>> Subject: Re: Introduce IOException subclass for ECONNRESET >>> >>> On 12/09/16 14:50, Florian Weimer wrote: >>>> On 08/23/2016 09:40 AM, Norman Maurer wrote: >>>>> Hi all, >>>>> >>>>> I first asked this on nio-dev[0] but was asked to move this over to >>>>> here: >>>>> >>>>> I wonder if it would be possible to add a new IOException sub-class >>>>> for ECONNRESET. Often you receive these errors if a remote peer closed >>>>> the connection and you try to read from it while using NIO. This is >>>>> very often not really something that concerns people and can just be >>>>> handled the same as a ?normal close?. >>> >>> So what are the other cases, where ECONNRESET may occur? What is >>> equivalent on non-Unix platforms, Windows for example? >>> >>> >> At the moment the only way to >>>>> detect this is to inspect the IOException message which is really >>>>> hacky. >>> >>> Do you have examples of code that does this today? >>> >>>>> I wonder if we could not add a special IOException sub-class >>>>> for this. Something like: >>>>> >>>>> ConnectionResetException extends IOException { >>>>> } >>>> >>>> Shouldn't it be a subclass of SocketException? >>> >>> I think it would have to be a subclass of SocketException too, for >>> compatibility at least, since that is the type that is thrown >>> today. >>> >>> sun.net.ConnectionResetException exists today, but I don't think >>> that it ever finds its way outside of the implementation. And is >>> of course not part of Java SE. >>> >>> -Chris. >>> >> > From vyom.tewari at oracle.com Thu Oct 6 07:31:56 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 6 Oct 2016 13:01:56 +0530 Subject: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty Message-ID: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> Hi All, Please find the spec change for below issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 Webrev : http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html The reason of this change is a side effect of a recent past fix [1] changed the behavior of URLPermission to omit the colon separator when the request headers list is empty (the spec allows this). However some previously existing tests started failing [2] because of that. As the spec allows the colon separator to be always present, whether the request list is empty or not. For the sake of backward compatibility with existing code that might expect getActions() to always return a string containing a colon we chooses the conservative approach and continue to add the colon separator in all cases. [1] https://bugs.openjdk.java.net/browse/JDK-8114860 [2] https://bugs.openjdk.java.net/browse/JDK-8161291 Note: i will file a CCC for this spec change. Thanks, Vyom From daniel.fuchs at oracle.com Thu Oct 6 09:34:43 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Oct 2016 10:34:43 +0100 Subject: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty In-Reply-To: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> References: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> Message-ID: Hi Vyom, So if I understand well, the class level API documentation allowed for the colon to be either omitted or present: 121 *

122 * The colon separator need not be present if the request headers list is empty. but the getActions() javadoc indicated that the colon would be omitted if there were no headers: 219 * There is no white space in the returned String. If header-names is empty 220 * then the colon separator will not be present. However, the JDK implementation used to always include the colon, in contradiction to lines #219-220. We tried to bring the implementation in conformance to line #219-220, but this caused failures in serialization tests (see JDK-8161291 [2]) - so we reverted to always include the colon for the sake of interoperability and serial-compatibility with previous releases. Now this fix (8163482) is just to alter the spec of getActions(), lines #219-220 to match the spec at line #122 and acknowledge the existing behavior. Did I get it right? best regards, -- daniel On 06/10/16 08:31, Vyom Tewari wrote: > Hi All, > > Please find the spec change for below issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 > > Webrev : > http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html > > > The reason of this change is a side effect of a recent past fix [1] > changed the behavior of URLPermission to omit the colon separator when > the request headers list is empty (the spec allows this). However some > previously existing tests started failing [2] because of that. > > As the spec allows the colon separator to be always present, whether > the request list is empty or not. For the sake of backward compatibility > with existing code that might expect getActions() to always return a > string containing a colon we chooses the conservative approach and > continue to add the colon separator in all cases. > > [1] https://bugs.openjdk.java.net/browse/JDK-8114860 > [2] https://bugs.openjdk.java.net/browse/JDK-8161291 > > Note: i will file a CCC for this spec change. > > Thanks, > > Vyom > From vyom.tewari at oracle.com Thu Oct 6 10:46:29 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Thu, 6 Oct 2016 16:16:29 +0530 Subject: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty In-Reply-To: References: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> Message-ID: On Thursday 06 October 2016 03:04 PM, Daniel Fuchs wrote: > Hi Vyom, > > So if I understand well, the class level API documentation allowed > for the colon to be either omitted or present: > > 121 *

> 122 * The colon separator need not be present if the request headers > list is empty. > > but the getActions() javadoc indicated that the colon would be > omitted if there were no headers: > > 219 * There is no white space in the returned String. If > header-names is empty > 220 * then the colon separator will not be present. > > However, the JDK implementation used to always include the > colon, in contradiction to lines #219-220. > We tried to bring the implementation in conformance to line > #219-220, but this caused failures in serialization tests > (see JDK-8161291 [2]) - so we reverted to always include > the colon for the sake of interoperability and serial-compatibility > with previous releases. > > Now this fix (8163482) is just to alter the spec of getActions(), > lines #219-220 to match the spec at line #122 and acknowledge > the existing behavior. > > Did I get it right? > yes , you are right. Vyom > best regards, > > -- daniel > > > On 06/10/16 08:31, Vyom Tewari wrote: >> Hi All, >> >> Please find the spec change for below issue. >> >> BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 >> >> Webrev : >> http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html >> >> >> The reason of this change is a side effect of a recent past fix [1] >> changed the behavior of URLPermission to omit the colon separator when >> the request headers list is empty (the spec allows this). However some >> previously existing tests started failing [2] because of that. >> >> As the spec allows the colon separator to be always present, whether >> the request list is empty or not. For the sake of backward compatibility >> with existing code that might expect getActions() to always return a >> string containing a colon we chooses the conservative approach and >> continue to add the colon separator in all cases. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8114860 >> [2] https://bugs.openjdk.java.net/browse/JDK-8161291 >> >> Note: i will file a CCC for this spec change. >> >> Thanks, >> >> Vyom >> > From daniel.fuchs at oracle.com Thu Oct 6 10:58:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Oct 2016 11:58:00 +0100 Subject: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty In-Reply-To: References: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> Message-ID: <2e1fd85a-3a93-94f2-9658-13954035d6f9@oracle.com> On 06/10/16 11:46, Vyom Tewari wrote: > > > On Thursday 06 October 2016 03:04 PM, Daniel Fuchs wrote: >> Hi Vyom, >> >> So if I understand well, the class level API documentation allowed >> for the colon to be either omitted or present: >> >> 121 *

>> 122 * The colon separator need not be present if the request headers >> list is empty. >> >> but the getActions() javadoc indicated that the colon would be >> omitted if there were no headers: >> >> 219 * There is no white space in the returned String. If >> header-names is empty >> 220 * then the colon separator will not be present. >> >> However, the JDK implementation used to always include the >> colon, in contradiction to lines #219-220. >> We tried to bring the implementation in conformance to line >> #219-220, but this caused failures in serialization tests >> (see JDK-8161291 [2]) - so we reverted to always include >> the colon for the sake of interoperability and serial-compatibility >> with previous releases. >> >> Now this fix (8163482) is just to alter the spec of getActions(), >> lines #219-220 to match the spec at line #122 and acknowledge >> the existing behavior. >> >> Did I get it right? >> > yes , you are right. Then this looks OK for me, provided the paper work for the spec change is filed and accepted. best regards, -- daniel > Vyom > >> best regards, >> >> -- daniel >> >> >> On 06/10/16 08:31, Vyom Tewari wrote: >>> Hi All, >>> >>> Please find the spec change for below issue. >>> >>> BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 >>> >>> Webrev : >>> http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html >>> >>> >>> The reason of this change is a side effect of a recent past fix [1] >>> changed the behavior of URLPermission to omit the colon separator when >>> the request headers list is empty (the spec allows this). However some >>> previously existing tests started failing [2] because of that. >>> >>> As the spec allows the colon separator to be always present, whether >>> the request list is empty or not. For the sake of backward compatibility >>> with existing code that might expect getActions() to always return a >>> string containing a colon we chooses the conservative approach and >>> continue to add the colon separator in all cases. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8114860 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8161291 >>> >>> Note: i will file a CCC for this spec change. >>> >>> Thanks, >>> >>> Vyom >>> >> > From chris.hegarty at oracle.com Thu Oct 6 11:16:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 6 Oct 2016 12:16:07 +0100 Subject: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty In-Reply-To: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> References: <04187eb2-6727-7a44-8547-244bc7ed4956@oracle.com> Message-ID: <7EF0455C-5FE3-43E5-B447-E4EDAEBF0B3B@oracle.com> > On 6 Oct 2016, at 08:31, Vyom Tewari wrote: > > Hi All, > > Please find the spec change for below issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8163482 > > Webrev : http://cr.openjdk.java.net/~vtewari/8163482/webrev0.0/index.html Thanks Vyom, this looks good. -Chris. > The reason of this change is a side effect of a recent past fix [1] changed the behavior of URLPermission to omit the colon separator when the request headers list is empty (the spec allows this). However some previously existing tests started failing [2] because of that. > > As the spec allows the colon separator to be always present, whether the request list is empty or not. For the sake of backward compatibility with existing code that might expect getActions() to always return a string containing a colon we chooses the conservative approach and continue to add the colon separator in all cases. > > [1] https://bugs.openjdk.java.net/browse/JDK-8114860 > [2] https://bugs.openjdk.java.net/browse/JDK-8161291 > > Note: i will file a CCC for this spec change. > > Thanks, > > Vyom > From christoph.langer at sap.com Thu Oct 6 15:43:37 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 6 Oct 2016 15:43:37 +0000 Subject: RFR(L): 8167295: Contribute further changes from SAP to native parts of libnet/libnio Message-ID: <39b854eaa42a4417a401ff52633d3d1b@DEWDFE13DE11.global.corp.sap> Hi, I'm looking to contribute a few of our diffs in the network area to OpenJDK. This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295 This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/ Besides minor cleanups, initializations and fixes, the main thing that I'm proposing is the unification of the union datatype SOCKADDR (unix) and SOCKETADDRESS (windows). I think the definition for all platforms should basically look like the following, of course depending on IPv6 support and the local datatypes: typedef union { struct sockaddr him; struct sockaddr_in him4; struct sockaddr_in6 him6; } SOCKETADDRESS; The type 'SOCKADDR' is already defined on Windows so we should consistently use 'SOCKETADDRESS'. This move would allow for better writing of shared code dealing with sockaddr structures, which we do at SAP especially for some tracing code. I don't know yet if it's a good idea to get rid of the definitions SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) and fully rely on sizeof(SOCKETADDRESS). I've done this in my webrev and it builds. But I'm not sure if especially some Windows APIs would behave strangely if passed in a longer length values for an AF_INET socket address. Maybe you have some comments on that point. Apart from that, I think it is a good idea to get rid of 'NET_AllocSockaddr' as there is no need to malloc SOCKETADDRESS fields at the few places where it was used (libnio unix only). A stack variable would probably be better and less error prone. And the declaration of NET_Wait can move to the common net_util.h header as the function is available everywhere with the same signature. Right now I'm just at a stage where my change builds on all platforms and I need to do some further testing. But I'm hoping for some early comments :) Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From MClaassen at ocie.net Thu Oct 6 18:58:45 2016 From: MClaassen at ocie.net (Mark A. Claassen) Date: Thu, 6 Oct 2016 18:58:45 +0000 Subject: Proxies Message-ID: After asking some questions at JavaOne, I was told I could get more complete answers here. My question is about authentication mechanisms and support for native network configurations. Is the new client going to have access to the system proxy configuration settings? It would be nice if there was a natural way to use the system keystores as well. This is a real pain-point for our rollouts. People log in to their computers (generally Windows and Macs for our users) and, if they can access the web in their browser, they think that our application should be able to as well. However, we have to ask them to try to duplicate their settings in our application. Many times this involves an authenticating proxy. Is this possible to do with the new HttpClient? Is it possible without jumping through a lot of hoops? (Currently we are using the Apache HttpClient library, which has hooks where we can do some proxy authentication.) Thanks, Mark Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. From ecki at zusammenkunft.net Thu Oct 6 19:17:15 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 6 Oct 2016 21:17:15 +0200 Subject: Proxies In-Reply-To: References: Message-ID: <20161006211715.0000717c.ecki@zusammenkunft.net> Hello, Java HTTP clients (HTPURLConnection) can use a limited functionality of the system proxy. If you use Applet/JWS it is also configured on the cotnrol panel. http://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html You can also access system key and trust stores (with limited functionality). You would use storeType=Windows-MY or Windows-root: C:> keytool -list -storetype Windows-MY Keystore-Typ: Windows-MY Keystore-Provider: SunMSCAPI PNRP (Naming), PrivateKeyEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx.. BitLocker, trustedCertEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx... Eckenfels. Bernd, PrivateKeyEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx.. ... Greetings Bernd Am Thu, 6 Oct 2016 18:58:45 +0000 schrieb "Mark A. Claassen" : > After asking some questions at JavaOne, I was told I could get more > complete answers here. My question is about authentication mechanisms > and support for native network configurations. > > Is the new client going to have access to the system proxy > configuration settings? It would be nice if there was a natural way > to use the system keystores as well. > > This is a real pain-point for our rollouts. People log in to their > computers (generally Windows and Macs for our users) and, if they can > access the web in their browser, they think that our application > should be able to as well. However, we have to ask them to try to > duplicate their settings in our application. Many times this > involves an authenticating proxy. Is this possible to do with the > new HttpClient? Is it possible without jumping through a lot of > hoops? > > (Currently we are using the Apache HttpClient library, which has > hooks where we can do some proxy authentication.) > > Thanks, > Mark > > Disclaimer: > The opinions provided herein do not necessarily state or reflect > those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and > assumes no legal liability or responsibility for the posting. > From MClaassen at ocie.net Thu Oct 6 19:53:27 2016 From: MClaassen at ocie.net (Mark A. Claassen) Date: Thu, 6 Oct 2016 19:53:27 +0000 Subject: Proxies In-Reply-To: <20161006211715.0000717c.ecki@zusammenkunft.net> References: <20161006211715.0000717c.ecki@zusammenkunft.net> Message-ID: <1851874210b544959051d9b9654bc16d@MailCorp01.ocie.net> Thanks for your reply. We used to use JWS, but have decided not move away from that technology. The proxy issue is my biggest problem right now. If the system would know that a proxy is involved, pick it, and use whatever native authentication mechanism it might need, I would be all set. However, if it just tells me what the proxy is, I would still need a way to get the credentials (Active Directory stuff, for instance). It looked like the new HttpClient library uses many of the same SSL libraries (like SSLContext, TrustManager, ...), but if there isn't a way to authentication through a proxy, it is all for not. Mark Disclaimer: The opinions provided herein do not necessarily state or reflect those of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes no legal liability or responsibility for the posting. -----Original Message----- From: Bernd Eckenfels [mailto:ecki at zusammenkunft.net] Sent: Thursday, October 06, 2016 3:17 PM To: net-dev at openjdk.java.net Subject: Re: Proxies Hello, Java HTTP clients (HTPURLConnection) can use a limited functionality of the system proxy. If you use Applet/JWS it is also configured on the cotnrol panel. http://docs.oracle.com/javase/8/docs/technotes/guides/net/proxies.html You can also access system key and trust stores (with limited functionality). You would use storeType=Windows-MY or Windows-root: C:> keytool -list -storetype Windows-MY Keystore-Typ: Windows-MY Keystore-Provider: SunMSCAPI PNRP (Naming), PrivateKeyEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx.. BitLocker, trustedCertEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx... Eckenfels. Bernd, PrivateKeyEntry, Zertifikat-Fingerprint (SHA1): xx:xx:xx:xx:xx:xx:xx.. ... Greetings Bernd Am Thu, 6 Oct 2016 18:58:45 +0000 schrieb "Mark A. Claassen" : > After asking some questions at JavaOne, I was told I could get more > complete answers here. My question is about authentication mechanisms > and support for native network configurations. > > Is the new client going to have access to the system proxy > configuration settings? It would be nice if there was a natural way > to use the system keystores as well. > > This is a real pain-point for our rollouts. People log in to their > computers (generally Windows and Macs for our users) and, if they can > access the web in their browser, they think that our application > should be able to as well. However, we have to ask them to try to > duplicate their settings in our application. Many times this involves > an authenticating proxy. Is this possible to do with the new > HttpClient? Is it possible without jumping through a lot of hoops? > > (Currently we are using the Apache HttpClient library, which has hooks > where we can do some proxy authentication.) > > Thanks, > Mark > > Disclaimer: > The opinions provided herein do not necessarily state or reflect those > of Donnell Systems, Inc.(DSI). DSI makes no warranty for and assumes > no legal liability or responsibility for the posting. > From christoph.langer at sap.com Fri Oct 7 15:17:05 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 7 Oct 2016 15:17:05 +0000 Subject: RFR(L): 8167295: Further cleanup to the native parts of libnet/libnio Message-ID: <5d9ce3b78da9480490e36bcea3159cb2@DEWDFE13DE11.global.corp.sap> Hi again, I have respun my patch a little bit: http://cr.openjdk.java.net/~clanger/webrevs/8167295.1/ The reason is that the naming of the members of SOCKETADDRESS should be changed to 'sa' instead of 'him' as the fields are of type 'struct sockaddr...'. I also did a careful inspection of the places where SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) used to be used and found that it should really be ok if this define is completely dropped and always sizeof(SOCKETADDRESS) at these places. Basic testing showed that the changes were ok - I'll add the patch to the queue for our nightly build/test runs and check for regressions... Thanks Christoph From: Langer, Christoph Sent: Donnerstag, 6. Oktober 2016 17:44 To: net-dev at openjdk.java.net Cc: nio-dev at openjdk.java.net Subject: RFR(L): 8167295: Contribute further changes from SAP to native parts of libnet/libnio Hi, I'm looking to contribute a few of our diffs in the network area to OpenJDK. This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295 This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/ Besides minor cleanups, initializations and fixes, the main thing that I'm proposing is the unification of the union datatype SOCKADDR (unix) and SOCKETADDRESS (windows). I think the definition for all platforms should basically look like the following, of course depending on IPv6 support and the local datatypes: typedef union { struct sockaddr him; struct sockaddr_in him4; struct sockaddr_in6 him6; } SOCKETADDRESS; The type 'SOCKADDR' is already defined on Windows so we should consistently use 'SOCKETADDRESS'. This move would allow for better writing of shared code dealing with sockaddr structures, which we do at SAP especially for some tracing code. I don't know yet if it's a good idea to get rid of the definitions SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) and fully rely on sizeof(SOCKETADDRESS). I've done this in my webrev and it builds. But I'm not sure if especially some Windows APIs would behave strangely if passed in a longer length values for an AF_INET socket address. Maybe you have some comments on that point. Apart from that, I think it is a good idea to get rid of 'NET_AllocSockaddr' as there is no need to malloc SOCKETADDRESS fields at the few places where it was used (libnio unix only). A stack variable would probably be better and less error prone. And the declaration of NET_Wait can move to the common net_util.h header as the function is available everywhere with the same signature. Right now I'm just at a stage where my change builds on all platforms and I need to do some further testing. But I'm hoping for some early comments :) Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.smotrakov at oracle.com Fri Oct 7 20:33:58 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 7 Oct 2016 13:33:58 -0700 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently Message-ID: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Hello, Please review the patch below for sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. The test has been observed to fail intermittently, but the failure is not reproducible standalone. The patch updates the test to follow the approach from SSLSocketSample.java http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java I merged OriginServer.java to ProxyAuthTest.java since only this test uses that file. I also added a couple of new common methods to SSLTest.java. They are not used by ProxyAuthTest.java, but can be useful in other tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ Artem From christoph.langer at sap.com Mon Oct 10 07:31:31 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Oct 2016 07:31:31 +0000 Subject: RFR(S): 8167420: remove redundant code path in unix/native/libnet/Inet4AddressImpl.c Message-ID: <9596599548934f358e46bfdf8d21a5ce@DEWDFE13DE11.global.corp.sap> Hi, here's another review request for a cleanup: Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167420.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8167420 In unix/native/libnet/Inet4AddressImpl.c, there exist 2 implementations for each of Java_java_net_Inet4AddressImpl_getLocalHostName, Java_java_net_Inet4AddressImpl_lookupAllHostAddr and Java_java_net_Inet4AddressImpl_getHostByAddr. I think one branch is obsolete. I also did some cleanups in those functions. One question that I still have is if we should add the MACOSX workaround path when getaddrinfo returns error and "lookupIfLocalhost" is called? However, as it was not part of the standard branch which is probably used mostly on MacOSX nowadays, I tend to remove it. In the webrev it is still contained. The changeset is based on my proposal for 8167295 (http://cr.openjdk.java.net/~clanger/webrevs/8167295.1/). Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Oct 10 12:07:51 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Oct 2016 13:07:51 +0100 Subject: RFR(L): 8167295: Further cleanup to the native parts of libnet/libnio In-Reply-To: <5d9ce3b78da9480490e36bcea3159cb2@DEWDFE13DE11.global.corp.sap> References: <5d9ce3b78da9480490e36bcea3159cb2@DEWDFE13DE11.global.corp.sap> Message-ID: <53a7ee60-341c-60b1-3910-4e1bb0dd2798@oracle.com> Hi Christoph, On 07/10/16 16:17, Langer, Christoph wrote: > Hi again, > > I have respun my patch a little bit: > http://cr.openjdk.java.net/~clanger/webrevs/8167295.1/ This is a nice cleanup and an improvement to the code. Specifically, adding 'struct sockaddr sa' to SOCKETADDRESS allows for the removal of many cast operations. One minor double space I noticed when reviewing the changes. Net.c 339 sa.sa4.sin_len = sizeof(struct sockaddr_in); ^^ My eyes hurt from this kind of review, e.g. addrs->addr.sa6.sin6_addr.s6_addr!!! so I put your patch through our internal build and test system too. All looks good. -Chris. > The reason is that the naming of the members of SOCKETADDRESS should be > changed to ?sa? instead of ?him? as the fields are of type ?struct > sockaddr??. I also did a careful inspection of the places where > SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) used to be used and found that > it should really be ok if this define is completely dropped and always > sizeof(SOCKETADDRESS) at these places. Basic testing showed that the > changes were ok ? I?ll add the patch to the queue for our nightly > build/test runs and check for regressions? > > > > Thanks > > Christoph > > > > > > *From:*Langer, Christoph > *Sent:* Donnerstag, 6. Oktober 2016 17:44 > *To:* net-dev at openjdk.java.net > *Cc:* nio-dev at openjdk.java.net > *Subject:* RFR(L): 8167295: Contribute further changes from SAP to > native parts of libnet/libnio > > > > Hi, > > > > I?m looking to contribute a few of our diffs in the network area to OpenJDK. > > > > This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295 > > This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/ > > > > Besides minor cleanups, initializations and fixes, the main thing that > I?m proposing is the unification of the union datatype SOCKADDR (unix) > and SOCKETADDRESS (windows). > > > > I think the definition for all platforms should basically look like the > following, of course depending on IPv6 support and the local datatypes: > > > > typedef union { > > struct sockaddr him; > > struct sockaddr_in him4; > > struct sockaddr_in6 him6; > > } SOCKETADDRESS; > > > > The type ?SOCKADDR? is already defined on Windows so we should > consistently use ?SOCKETADDRESS?. This move would allow for better > writing of shared code dealing with sockaddr structures, which we do at > SAP especially for some tracing code. > > > > I don?t know yet if it?s a good idea to get rid of the definitions > SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) and fully rely on > sizeof(SOCKETADDRESS). I?ve done this in my webrev and it builds. But > I?m not sure if especially some Windows APIs would behave strangely if > passed in a longer length values for an AF_INET socket address. Maybe > you have some comments on that point. > > > > Apart from that, I think it is a good idea to get rid of > ?NET_AllocSockaddr? as there is no need to malloc SOCKETADDRESS fields > at the few places where it was used (libnio unix only). A stack variable > would probably be better and less error prone. And the declaration of > NET_Wait can move to the common net_util.h header as the function is > available everywhere with the same signature. > > > > Right now I?m just at a stage where my change builds on all platforms > and I need to do some further testing. But I?m hoping for some early > comments J > > > > Thanks and best regards > > Christoph > > > From christoph.langer at sap.com Mon Oct 10 20:51:48 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 10 Oct 2016 20:51:48 +0000 Subject: RFR(L): 8167295: Further cleanup to the native parts of libnet/libnio In-Reply-To: <53a7ee60-341c-60b1-3910-4e1bb0dd2798@oracle.com> References: <5d9ce3b78da9480490e36bcea3159cb2@DEWDFE13DE11.global.corp.sap> <53a7ee60-341c-60b1-3910-4e1bb0dd2798@oracle.com> Message-ID: <1e35891dffd040c9ba582a6c5bef7e01@DEWDFE13DE11.global.corp.sap> Hi Chris, thanks for the review. We couldn't observe issues in our OpenJDK test systems and most of the change was part of the SAP JVM already for quite some time. So I pushed it just now: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d4f70e7859c7 Some more cleanup is still to come... :) Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Montag, 10. Oktober 2016 14:08 > To: Langer, Christoph ; net-dev at openjdk.java.net > Cc: nio-dev at openjdk.java.net > Subject: Re: RFR(L): 8167295: Further cleanup to the native parts of > libnet/libnio > > Hi Christoph, > > On 07/10/16 16:17, Langer, Christoph wrote: > > Hi again, > > > > I have respun my patch a little bit: > > http://cr.openjdk.java.net/~clanger/webrevs/8167295.1/ > > This is a nice cleanup and an improvement to the code. Specifically, > adding 'struct sockaddr sa' to SOCKETADDRESS allows for the removal > of many cast operations. > > One minor double space I noticed when reviewing the changes. > > Net.c > 339 sa.sa4.sin_len = sizeof(struct sockaddr_in); > ^^ > > My eyes hurt from this kind of review, e.g. > addrs->addr.sa6.sin6_addr.s6_addr!!! so I put your patch through > our internal build and test system too. All looks good. > > -Chris. > > > > > The reason is that the naming of the members of SOCKETADDRESS should be > > changed to 'sa' instead of 'him' as the fields are of type 'struct > > sockaddr...'. I also did a careful inspection of the places where > > SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) used to be used and found > that > > it should really be ok if this define is completely dropped and always > > sizeof(SOCKETADDRESS) at these places. Basic testing showed that the > > changes were ok - I'll add the patch to the queue for our nightly > > build/test runs and check for regressions... > > > > > > > > Thanks > > > > Christoph > > > > > > > > > > > > *From:*Langer, Christoph > > *Sent:* Donnerstag, 6. Oktober 2016 17:44 > > *To:* net-dev at openjdk.java.net > > *Cc:* nio-dev at openjdk.java.net > > *Subject:* RFR(L): 8167295: Contribute further changes from SAP to > > native parts of libnet/libnio > > > > > > > > Hi, > > > > > > > > I'm looking to contribute a few of our diffs in the network area to OpenJDK. > > > > > > > > This is the bug: https://bugs.openjdk.java.net/browse/JDK-8167295 > > > > This is the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8167295.0/ > > > > > > > > Besides minor cleanups, initializations and fixes, the main thing that > > I'm proposing is the unification of the union datatype SOCKADDR (unix) > > and SOCKETADDRESS (windows). > > > > > > > > I think the definition for all platforms should basically look like the > > following, of course depending on IPv6 support and the local datatypes: > > > > > > > > typedef union { > > > > struct sockaddr him; > > > > struct sockaddr_in him4; > > > > struct sockaddr_in6 him6; > > > > } SOCKETADDRESS; > > > > > > > > The type 'SOCKADDR' is already defined on Windows so we should > > consistently use 'SOCKETADDRESS'. This move would allow for better > > writing of shared code dealing with sockaddr structures, which we do at > > SAP especially for some tracing code. > > > > > > > > I don't know yet if it's a good idea to get rid of the definitions > > SOCKADDR_LEN resp. SOCKETADDRESS_LEN(x) and fully rely on > > sizeof(SOCKETADDRESS). I've done this in my webrev and it builds. But > > I'm not sure if especially some Windows APIs would behave strangely if > > passed in a longer length values for an AF_INET socket address. Maybe > > you have some comments on that point. > > > > > > > > Apart from that, I think it is a good idea to get rid of > > 'NET_AllocSockaddr' as there is no need to malloc SOCKETADDRESS fields > > at the few places where it was used (libnio unix only). A stack variable > > would probably be better and less error prone. And the declaration of > > NET_Wait can move to the common net_util.h header as the function is > > available everywhere with the same signature. > > > > > > > > Right now I'm just at a stage where my change builds on all platforms > > and I need to do some further testing. But I'm hoping for some early > > comments J > > > > > > > > Thanks and best regards > > > > Christoph > > > > > > From christoph.langer at sap.com Wed Oct 12 12:16:50 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 12 Oct 2016 12:16:50 +0000 Subject: RFR (M): 8167481: cleanup of headers and includes for native libnet Message-ID: <6b9bf6e7c557460c9504faeecabf7ccd@DEWDFE13DE11.global.corp.sap> Hi, as I already mentioned, here is another proposal for cleanup in libnet: https://bugs.openjdk.java.net/browse/JDK-8167481 http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ This time I touched the includes. Generally I reordered the includes to include "net_util.h" first, then any JNI includes, such as "java_net_InetAddress.h" and finally all standard header includes in alphabetical order. For platform specific includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that don't seem to be necessary to get the respective file compiled. Is that the correct approach that is desired? To make this work, I had to remove the definitions "IPv4" and "IPv6" in net_util.h and replace their usages with "java_net_InetAddress_IPv4" resp. "java_net_InetAddress_IPv6" from JNI which seems to be the correct thing to do anyway. For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 in net_util_md.h and replaced all occurences with sockaddr_in6. It seems that the capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even older than Visual Studio 2003. So I'm wondering if I should remove the whole section in windows net_util_md.h now (lines 47 - 177)? For Windows it seems that we can also completely get rid of src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought by the #include . Would you agree to that? So far I successfully ran builds in my local environments for Windows, Linux, AIX, Solaris and Apple. I've now added the changeset to our local regression testing environment for OpenJDK. If the change is to your like, I would like to ask you to also run it through JPRT to see if I missed some dependency. Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Oct 13 06:19:23 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 13 Oct 2016 06:19:23 +0000 Subject: AF_INET6 support Message-ID: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> Hi networking experts, I've got a question regarding AF_INET6. In jdk native code you'll still find lots of code guarded by "#ifdef AF_INET6". I'm wondering if there are still supported build environments where AF_INET6 is not defined. Or is it time now to assume AF_INET6 and remove this guarding? Here at SAP we don't support non AF_INET6 build environments for quite a long time already. But probably there are scenarios out in the Java world where only IPv4 builds are done?? Maybe you can shed some light on this and/or give your opinion? Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Oct 13 08:28:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Oct 2016 09:28:12 +0100 Subject: AF_INET6 support In-Reply-To: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> References: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> Message-ID: <098BBC2F-4535-4A66-BB05-BF67E5E3977F@oracle.com> Christoph, > On 13 Oct 2016, at 07:19, Langer, Christoph wrote: > > Hi networking experts, > > I?ve got a question regarding AF_INET6. > > In jdk native code you?ll still find lots of code guarded by ?#ifdef AF_INET6?. I?m wondering if there are still supported build environments where AF_INET6 is not defined. Or is it time now to assume AF_INET6 and remove this guarding? Here at SAP we don?t support non AF_INET6 build environments for quite a long time already. But probably there are scenarios out in the Java world where only IPv4 builds are done?? > > Maybe you can shed some light on this and/or give your opinion? A while back we did consider removing #ifdef AF_INET6, so that the code could be cleaned up and made more readable, but we never got around to it ( it was just lower priority than other tasks ). I do remember fixing, or sponsoring, a change in the last year or so, where an #ifdef AF_INET6 was missing, that make me think that it was good that we did not remove these ( i.e. the person that filed the bug had a good use-case for building without IPv6 support ). I?ll see if I can jog my memory by looking through history. -Chris. From Alan.Bateman at oracle.com Thu Oct 13 08:37:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Oct 2016 09:37:47 +0100 Subject: AF_INET6 support In-Reply-To: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> References: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> Message-ID: <881f96c1-cb2c-49f9-a0fc-91bea00dc509@oracle.com> On 13/10/2016 07:19, Langer, Christoph wrote: > > Hi networking experts, > > I?ve got a question regarding AF_INET6. > > In jdk native code you?ll still find lots of code guarded by ?#ifdef > AF_INET6?. I?m wondering if there are still supported build > environments where AF_INET6 is not defined. Or is it time now to > assume AF_INET6 and remove this guarding? Here at SAP we don?t support > non AF_INET6 build environments for quite a long time already. But > probably there are scenarios out in the Java world where only IPv4 > builds are done?? > > Maybe you can shed some light on this and/or give your opinion? > > It dates back to when IPv6 support was initially added and when there wasn't support on all platforms. Also there was a long period where it was supported to cross build to older (mostly embedded) platform that didn't have IPv6. I'm not aware of any now and don't see any reason not to clean this up. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Oct 13 08:46:59 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 13 Oct 2016 08:46:59 +0000 Subject: AF_INET6 support In-Reply-To: <098BBC2F-4535-4A66-BB05-BF67E5E3977F@oracle.com> References: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> <098BBC2F-4535-4A66-BB05-BF67E5E3977F@oracle.com> Message-ID: <9e5d1e66416a4ac895457cff65bd4b49@DEWDFE13DE11.global.corp.sap> Hi Chris, > > I?ve got a question regarding AF_INET6. > > > > In jdk native code you?ll still find lots of code guarded by ?#ifdef AF_INET6?. > I?m wondering if there are still supported build environments where AF_INET6 > is not defined. Or is it time now to assume AF_INET6 and remove this guarding? > Here at SAP we don?t support non AF_INET6 build environments for quite a long > time already. But probably there are scenarios out in the Java world where only > IPv4 builds are done?? > > > > Maybe you can shed some light on this and/or give your opinion? > > A while back we did consider removing #ifdef AF_INET6, so that the > code could be cleaned up and made more readable, but we never got > around to it ( it was just lower priority than other tasks ). I do remember > fixing, or sponsoring, a change in the last year or so, where an #ifdef > AF_INET6 was missing, that make me think that it was good that we > did not remove these ( i.e. the person that filed the bug had a good > use-case for building without IPv6 support ). I?ll see if I can jog my > memory by looking through history. Ok, it would really be great if you could find more information about that case where #ifdef AF_INET6 was missing and it lead to problems. But if nobody really does IPv4 only builds and tests the results, I doubt that the IPv4 only scenario would work or even build. Then I think it was likely that somehow unguarded IPv6 code sneaks in or has already done so... In case it can be removed it would really make the code more readable in several places. So, as I'm still doing cleanups, I could also take care of removing those #ifdefs at the places where I'm going. Just let me know. Thanks Christoph From christoph.langer at sap.com Mon Oct 17 08:38:31 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Oct 2016 08:38:31 +0000 Subject: [8u-dev] Request for Review + Approval: Backport of 8163181: Further improvements for Unix NetworkInterface native implementation Message-ID: <866c93003d63482bb147736a5aa9f058@DEWDFE13DE11.global.corp.sap> Hi, please review (@Chris or Mark) and approve the following downport. Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 Original Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2 New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163181.8udev/ Mail discussion: http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010207.html The main motivation for this downport is the bug in the AIX version of enumIPv6Interfaces. As the whole change is merely formatting, I decided to ask for a full downport. The patch does not apply cleanly, I had to resolve a little bit and also added some further formatting cleanups to be mostly identical with the JDK 9 version of NetworkInterface.c now. Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Oct 17 08:40:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 17 Oct 2016 08:40:38 +0000 Subject: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet Message-ID: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> Hi, is there any comments/reviews for my cleanup work here? The changeset was added to our local OpenJDK build and test infrastructure several days ago and it does not show issues... Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 12. Oktober 2016 14:17 To: net-dev at openjdk.java.net Subject: RFR (M): 8167481: cleanup of headers and includes for native libnet Hi, as I already mentioned, here is another proposal for cleanup in libnet: https://bugs.openjdk.java.net/browse/JDK-8167481 http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ This time I touched the includes. Generally I reordered the includes to include "net_util.h" first, then any JNI includes, such as "java_net_InetAddress.h" and finally all standard header includes in alphabetical order. For platform specific includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that don't seem to be necessary to get the respective file compiled. Is that the correct approach that is desired? To make this work, I had to remove the definitions "IPv4" and "IPv6" in net_util.h and replace their usages with "java_net_InetAddress_IPv4" resp. "java_net_InetAddress_IPv6" from JNI which seems to be the correct thing to do anyway. For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 in net_util_md.h and replaced all occurences with sockaddr_in6. It seems that the capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even older than Visual Studio 2003. So I'm wondering if I should remove the whole section in windows net_util_md.h now (lines 47 - 177)? For Windows it seems that we can also completely get rid of src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought by the #include . Would you agree to that? So far I successfully ran builds in my local environments for Windows, Linux, AIX, Solaris and Apple. I've now added the changeset to our local regression testing environment for OpenJDK. If the change is to your like, I would like to ask you to also run it through JPRT to see if I missed some dependency. Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Mon Oct 17 13:25:53 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 17 Oct 2016 14:25:53 +0100 Subject: Ugly things done to support multiple ContentHandlerFactory and URLStreamHandlerFactory In-Reply-To: References: Message-ID: Hi Tom, We are aware of some of these issues, but I have to admit that I still don't have a good handle on all the use-cases. One of the more straight forward is the "wrapping" of the built-in handlers, for the case where the framework does not want to re-implement all the existing JDK supported protocols when it wants to add, or intercept, on a small set, or even delegating for other reasons. I filed 8168076 [1] to track this. Let me know if this something that would help your specific case, or not. For your 'base' handler, is it possible that you deploy it as a service on the application class path ( using the new provider mechanism ), and have it provide the context sensitivity, based on TCCL or some such? The frameworks could register with it, and it could use the future API envisioned by 8168076 to delegate to the JDK's built-in handlers when needed. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8168076 On 13/10/16 16:46, Thomas Watson wrote: > Now that jigsaw is prohibiting deep reflection on types provided by the > boot modules we are running into an issue with the ugly things we do [1] > in order to support multiple factories in Equinox (an OSGi > implementation). Each Equinox instance has its own context aware > ContentHandlerFactory and URLStreamHandlerFactory which serves up handlers > that are available for the particular instance of Equinox. In order to do > this we have to resort to some very ugly reflection. This allows us to > gain access to the 'base' factory object set in the VM so that each > instance of the framework can register itself with the 'base' factory. The > 'base' factory handlers do the complicated work of figuring out which > factory to call based on the context which is calling the base handler. > > We also resort to reflection on framework shutdown in order to flush our > factories out from the VM so that the base factory is not pinning our > framework in memory. I am also aware that the Apache Felix OSGi Framework > implementation uses similar deep reflection in its implementation. Are > there any plans in Java 9 that will make this scenario easier to achieve > without resorting to the use of deep reflection on the URL types from the > VM? If not, are there going to be command line options that will allow us > to open up deep reflection of specific VM types as a compatibility mode > until we can get a proper solution? > > At a minimum I think we need someway to unset the statically set handlers > in the VM to avoid pinning our base factories. I can think of other > non-reflective ways to gain access to the base handler instance in order > to register each framework instance with the base handler. For example, > the base factory could implement a specific protocol which allows a > connection to register another framework. > > But we are still left with a delima of how to wrap the handlers returned > by various framework factory instances from the base handlers. All the > interesting methods on java.net.URLStreamHandler are protected. Even > though the proxy base handler extends java.net.URLStreamHandler it is not > allowed to call the protected methods on another instance of > java.net.URLStreamHandler. We resorted to deep reflection on the > java.net.URLStreamHandler class methods to do that. The > java.net.URLStreamHandler class is not an interface so we cannot easily > create proxy classes using java.lang.reflect.Proxy. > > Tom > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=502209 > > From artem.smotrakov at oracle.com Tue Oct 18 00:02:58 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Mon, 17 Oct 2016 17:02:58 -0700 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently In-Reply-To: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> References: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Message-ID: Hello, Please take a look. Artem On 10/07/2016 01:33 PM, Artem Smotrakov wrote: > Hello, > > Please review the patch below for > sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is > not reproducible standalone. The patch updates the test to follow the > approach from SSLSocketSample.java > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java > > > I merged OriginServer.java to ProxyAuthTest.java since only this test > uses that file. I also added a couple of new common methods to > SSLTest.java. They are not used by ProxyAuthTest.java, but can be > useful in other tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 > Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ > > Artem > From chris.hegarty at oracle.com Tue Oct 18 10:52:52 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Oct 2016 11:52:52 +0100 Subject: [8u-dev] Request for Review + Approval: Backport of 8163181: Further improvements for Unix NetworkInterface native implementation In-Reply-To: <866c93003d63482bb147736a5aa9f058@DEWDFE13DE11.global.corp.sap> References: <866c93003d63482bb147736a5aa9f058@DEWDFE13DE11.global.corp.sap> Message-ID: <4F20171F-1396-49E6-82A3-5056C76E4AF2@oracle.com> > On 17 Oct 2016, at 09:38, Langer, Christoph wrote: > > Hi, > > please review (@Chris or Mark) and approve the following downpour. From my point of view, I?m ok with this. You still need 8u maintainer approval. > Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 > Original Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2 > New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163181.8udev/ > Mail discussion: http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010207.html > > The main motivation for this downport is the bug in the AIX version of enumIPv6Interfaces. > > As the whole change is merely formatting, I decided to ask for a full downport. The patch does not apply cleanly, I had to resolve a little bit and also added some further formatting cleanups to be mostly identical with the JDK 9 version of NetworkInterface.c now. > > Thanks and best regards > Christoph -Chris. From christoph.langer at sap.com Tue Oct 18 10:54:45 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 18 Oct 2016 10:54:45 +0000 Subject: [8u-dev] Request for Review + Approval: Backport of 8163181: Further improvements for Unix NetworkInterface native implementation In-Reply-To: <4F20171F-1396-49E6-82A3-5056C76E4AF2@oracle.com> References: <866c93003d63482bb147736a5aa9f058@DEWDFE13DE11.global.corp.sap> <4F20171F-1396-49E6-82A3-5056C76E4AF2@oracle.com> Message-ID: <350e9c4d534349d28b4c33ef09f634c5@DEWDFE13DE11.global.corp.sap> Thanks, Chris. So then I'm asking for approval now... Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 18. Oktober 2016 12:53 > To: Langer, Christoph > Cc: jdk8u-dev at openjdk.java.net; Mark Sheppard > ; net-dev at openjdk.java.net > Subject: Re: [8u-dev] Request for Review + Approval: Backport of 8163181: > Further improvements for Unix NetworkInterface native implementation > > > > On 17 Oct 2016, at 09:38, Langer, Christoph > wrote: > > > > Hi, > > > > please review (@Chris or Mark) and approve the following downpour. > > From my point of view, I?m ok with this. You still need 8u maintainer approval. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163181 > > Original Change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/40c3550625a2 > > New Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8163181.8udev/ > > Mail discussion: http://mail.openjdk.java.net/pipermail/net-dev/2016- > September/010207.html > > > > The main motivation for this downport is the bug in the AIX version of > enumIPv6Interfaces. > > > > As the whole change is merely formatting, I decided to ask for a full > downport. The patch does not apply cleanly, I had to resolve a little bit and also > added some further formatting cleanups to be mostly identical with the JDK 9 > version of NetworkInterface.c now. > > > > Thanks and best regards > > Christoph > > -Chris. From chris.hegarty at oracle.com Tue Oct 18 10:57:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Oct 2016 11:57:01 +0100 Subject: AF_INET6 support In-Reply-To: <9e5d1e66416a4ac895457cff65bd4b49@DEWDFE13DE11.global.corp.sap> References: <964200b6d1bf43f6be476d531f00d3fb@DEWDFE13DE11.global.corp.sap> <098BBC2F-4535-4A66-BB05-BF67E5E3977F@oracle.com> <9e5d1e66416a4ac895457cff65bd4b49@DEWDFE13DE11.global.corp.sap> Message-ID: <48656747-9151-47F2-875D-A211AB0806FA@oracle.com> On 13 Oct 2016, at 09:46, Langer, Christoph wrote: > > Hi Chris, > >>> I?ve got a question regarding AF_INET6. >>> >>> In jdk native code you?ll still find lots of code guarded by ?#ifdef AF_INET6?. >> I?m wondering if there are still supported build environments where AF_INET6 >> is not defined. Or is it time now to assume AF_INET6 and remove this guarding? >> Here at SAP we don?t support non AF_INET6 build environments for quite a long >> time already. But probably there are scenarios out in the Java world where only >> IPv4 builds are done?? >>> >>> Maybe you can shed some light on this and/or give your opinion? >> >> A while back we did consider removing #ifdef AF_INET6, so that the >> code could be cleaned up and made more readable, but we never got >> around to it ( it was just lower priority than other tasks ). I do remember >> fixing, or sponsoring, a change in the last year or so, where an #ifdef >> AF_INET6 was missing, that make me think that it was good that we >> did not remove these ( i.e. the person that filed the bug had a good >> use-case for building without IPv6 support ). I?ll see if I can jog my >> memory by looking through history. > > Ok, it would really be great if you could find more information about that case where #ifdef AF_INET6 was missing and it lead to problems. > > But if nobody really does IPv4 only builds and tests the results, I doubt that the IPv4 only scenario would work or even build. Then I think it was likely that somehow unguarded IPv6 code sneaks in or has already done so... > > In case it can be removed it would really make the code more readable in several places. So, as I'm still doing cleanups, I could also take care of removing those #ifdefs at the places where I'm going. Just let me know. It appears that we do not have a requirement to be able to build IPv4 only. So, it should be possible to do the clean up that you are suggesting. If possible, can the change be kept as a single separate JIRA issue, so that we can easily identify the change in the future, if required. -Chris. From chris.hegarty at oracle.com Tue Oct 18 11:15:10 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Oct 2016 12:15:10 +0100 Subject: [9] RFR: 8166530: sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java fails intermittently In-Reply-To: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> References: <4e08a6c5-287b-a1eb-4a47-70c87b5781b2@oracle.com> Message-ID: > On 7 Oct 2016, at 21:33, Artem Smotrakov wrote: > > Hello, > > Please review the patch below for sun/net/www/protocol/https/HttpsClient/ProxyAuthTest.java test. > > The test has been observed to fail intermittently, but the failure is not reproducible standalone. The patch updates the test to follow the approach from SSLSocketSample.java > > http://hg.openjdk.java.net/jdk9/dev/jdk/file/1f044f413e6c/test/javax/net/ssl/templates/SSLSocketSample.java > > I merged OriginServer.java to ProxyAuthTest.java since only this test uses that file. I also added a couple of new common methods to SSLTest.java. They are not used by ProxyAuthTest.java, but can be useful in other tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166530 > Webrev: http://cr.openjdk.java.net/~asmotrak/8166530/webrev.00/ From my point of view, this looks ok. -Chris. From chris.hegarty at oracle.com Tue Oct 18 18:56:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 18 Oct 2016 19:56:03 +0100 Subject: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet In-Reply-To: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> References: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> Message-ID: <9B94F533-484F-4999-B597-AD797C8DAC55@oracle.com> Christoph, > On 17 Oct 2016, at 09:40, Langer, Christoph wrote: > ? > Hi, > > as I already mentioned, here is another proposal for cleanup in libnet: > https://bugs.openjdk.java.net/browse/JDK-8167481 > http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ Overall, this looks good. Specific comments below ... > This time I touched the includes. Generally I reordered the includes to include ?net_util.h? first, then any JNI includes, such as ?java_net_InetAddress.h? and finally all standard header includes in alphabetical order. For platform specific includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that don?t seem to be necessary to get the respective file compiled. Is that the correct approach that is desired? It is good to be consistent. My personal preference is to order the includes; 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) generated headers ( e.g. ?java_net_InetAddress.h? ). > To make this work, I had to remove the definitions ?IPv4? and ?IPv6? in net_util.h and replace their usages with ?java_net_InetAddress_IPv4? resp. ?java_net_InetAddress_IPv6? from JNI which seems to be the correct thing to do anyway. Right. This is a good change. Trivially, and it is not strictly necessary but good for readability, would be to add @Native to InetAddress.IPv4 and InetAddress.IPv6. > For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 in net_util_md.h and replaced all occurences with sockaddr_in6. It seems that the capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even older than Visual Studio 2003. So I?m wondering if I should remove the whole section in windows net_util_md.h now (lines 47 ? 177)? I think it should be ok to remove this. > For Windows it seems that we can also completely get rid of src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought by the #include . Would you agree to that? Ok. > So far I successfully ran builds in my local environments for Windows, Linux, AIX, Solaris and Apple. I?ve now added the changeset to our local regression testing environment for OpenJDK. If the change is to your like, I would like to ask you to also run it through JPRT to see if I missed some dependency. I ran your patch through our internal build and test system and there are no surprises. -Chris. > Thanks and best regards > Christoph From daniel.fuchs at oracle.com Wed Oct 19 14:52:59 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 19 Oct 2016 15:52:59 +0100 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger Message-ID: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> Hi, Please find below a patch that updates jdk.httpserver to use System.Logger. As a result jdk.httpserver no longer requires java.logging. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 issue: https://bugs.openjdk.java.net/browse/JDK-8157965 best regards, -- daniel From Roger.Riggs at Oracle.com Wed Oct 19 15:01:11 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 19 Oct 2016 11:01:11 -0400 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger In-Reply-To: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> References: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> Message-ID: <829c6f92-e5c9-5e57-8f22-64826496ca32@Oracle.com> Hi Daniel, looks fine. (The style differences are disconcerting but are consistent within the file). Roger On 10/19/2016 10:52 AM, Daniel Fuchs wrote: > Hi, > > Please find below a patch that updates jdk.httpserver to use > System.Logger. > > As a result jdk.httpserver no longer requires java.logging. > > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 > issue: https://bugs.openjdk.java.net/browse/JDK-8157965 > > best regards, > > -- daniel From daniel.fuchs at oracle.com Wed Oct 19 15:29:12 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 19 Oct 2016 16:29:12 +0100 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger In-Reply-To: <829c6f92-e5c9-5e57-8f22-64826496ca32@Oracle.com> References: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> <829c6f92-e5c9-5e57-8f22-64826496ca32@Oracle.com> Message-ID: <42d03b2d-c0dd-23d1-75af-cc34439c406f@oracle.com> Thanks Roger! On 19/10/16 16:01, Roger Riggs wrote: > Hi Daniel, > > looks fine. > > (The style differences are disconcerting but are consistent within the > file). Yes. I preserved the original style though it was hurting my eyes ;-) Having a mixed style was much worse. best regards, -- daniel > > Roger > > > On 10/19/2016 10:52 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a patch that updates jdk.httpserver to use >> System.Logger. >> >> As a result jdk.httpserver no longer requires java.logging. >> >> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 >> issue: https://bugs.openjdk.java.net/browse/JDK-8157965 >> >> best regards, >> >> -- daniel > From michael.x.mcmahon at oracle.com Wed Oct 19 15:40:59 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 19 Oct 2016 16:40:59 +0100 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger In-Reply-To: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> References: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> Message-ID: <5807940B.3050508@oracle.com> Looks good Daniel. Thanks, Michael On 19/10/2016, 15:52, Daniel Fuchs wrote: > Hi, > > Please find below a patch that updates jdk.httpserver to use > System.Logger. > > As a result jdk.httpserver no longer requires java.logging. > > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 > issue: https://bugs.openjdk.java.net/browse/JDK-8157965 > > best regards, > > -- daniel From mandy.chung at oracle.com Wed Oct 19 16:02:21 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 19 Oct 2016 09:02:21 -0700 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger In-Reply-To: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> References: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> Message-ID: <06588D98-0D60-472F-9FAB-B756EB0BFB57@oracle.com> > On Oct 19, 2016, at 7:52 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a patch that updates jdk.httpserver to use > System.Logger. > > As a result jdk.httpserver no longer requires java.logging. > > webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 > issue: https://bugs.openjdk.java.net/browse/JDK-8157965 Looks good. It?s good to see jdk code migrating to use System.Logger. Mandy From chris.hegarty at oracle.com Thu Oct 20 08:20:06 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Oct 2016 09:20:06 +0100 Subject: RFR: 8157965 update httpserver logging to use java.lang.System.Logger In-Reply-To: <42d03b2d-c0dd-23d1-75af-cc34439c406f@oracle.com> References: <053b5f70-7e55-fb25-8bef-54c65a09d2bb@oracle.com> <829c6f92-e5c9-5e57-8f22-64826496ca32@Oracle.com> <42d03b2d-c0dd-23d1-75af-cc34439c406f@oracle.com> Message-ID: > On 19 Oct 2016, at 16:29, Daniel Fuchs wrote: > > Thanks Roger! > > On 19/10/16 16:01, Roger Riggs wrote: >> Hi Daniel, >> >> looks fine. >> >> (The style differences are disconcerting but are consistent within the >> file). > > Yes. I preserved the original style though it was hurting > my eyes ;-) Having a mixed style was much worse. Looks good Daniel. Maybe worth a followup to run these files through a reasonable IDE reformatter. -Chris. > best regards, > > -- daniel > >> >> Roger >> >> >> On 10/19/2016 10:52 AM, Daniel Fuchs wrote: >>> Hi, >>> >>> Please find below a patch that updates jdk.httpserver to use >>> System.Logger. >>> >>> As a result jdk.httpserver no longer requires java.logging. >>> >>> webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8157965/webrev.00 >>> issue: https://bugs.openjdk.java.net/browse/JDK-8157965 >>> >>> best regards, >>> >>> -- daniel >> > From amy.lu at oracle.com Thu Oct 20 10:45:11 2016 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 20 Oct 2016 18:45:11 +0800 Subject: JDK 9 RFR of JDK-8146257: sun/net/www/protocol/jar/B4957695.java fails intermittently with java.lang.RuntimeException: some jar_cache files left behind Message-ID: sun/net/www/protocol/jar/B4957695.java This test is to verify that no jar_cache tmpFile left in temp directory when IOException occurs. Test do stream reading and trigger IOException and compare the jar_cache file number before and after this action (that triggered the IOException): String tmpdir = System.getProperty("java.io.tmpdir"); String[] list1 = listTmpFiles(tmpdir); ? // do stream reading, trigger IOException String[] list2 = listTmpFiles(tmpdir); if (!sameList (list1, list2)) { throw new RuntimeException ("some jar_cache files left behind"); } This does not work well when tests run concurrently, the jar_cache file under tmpdir may from other tests. Please review the patch to set "java.io.tmpdir" to current working dir to avoid test be affected by other tests. bug: https://bugs.openjdk.java.net/browse/JDK-8146257 webrev: http://cr.openjdk.java.net/~amlu/8146257/webrev.00/ Thanks, Amy --- old/test/sun/net/www/protocol/jar/B4957695.java 2016-10-20 17:04:00.000000000 +0800 +++ new/test/sun/net/www/protocol/jar/B4957695.java 2016-10-20 17:04:00.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -24,6 +24,7 @@ /** * @test * @bug 4957695 + * @run main/othervm -Djava.io.tmpdir=. B4957695 * @summary URLJarFile.retrieve does not delete tmpFile on IOException */ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Oct 20 11:38:50 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Oct 2016 12:38:50 +0100 Subject: JDK 9 RFR of JDK-8146257: sun/net/www/protocol/jar/B4957695.java fails intermittently with java.lang.RuntimeException: some jar_cache files left behind In-Reply-To: References: Message-ID: <6DB39750-6F75-4B09-B7BC-930D9BA334A9@oracle.com> > On 20 Oct 2016, at 11:45, Amy Lu wrote: > > sun/net/www/protocol/jar/B4957695.java > > This test is to verify that no jar_cache tmpFile left in temp directory when IOException occurs. > > Test do stream reading and trigger IOException and compare the jar_cache file number before and after this action (that triggered the IOException): > > String tmpdir = System.getProperty("java.io.tmpdir"); > String[] list1 = listTmpFiles(tmpdir); > ? // do stream reading, trigger IOException > String[] list2 = listTmpFiles(tmpdir); > if (!sameList (list1, list2)) { > throw new RuntimeException ("some jar_cache files left behind"); > } > > This does not work well when tests run concurrently, the jar_cache file under tmpdir may from other tests. > > Please review the patch to set "java.io.tmpdir" to current working dir to avoid test be affected by other tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8146257 > webrev: http://cr.openjdk.java.net/~amlu/8146257/webrev.00/ Thanks Amy, I think this change should help isolate the test from other interference in /tmp. -Chris. > Thanks, > Amy > > > --- old/test/sun/net/www/protocol/jar/B4957695.java 2016-10-20 17:04:00.000000000 +0800 > +++ new/test/sun/net/www/protocol/jar/B4957695.java 2016-10-20 17:04:00.000000000 +0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2003, 2012, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -24,6 +24,7 @@ > /** > * @test > * @bug 4957695 > + * @run main/othervm -Djava.io.tmpdir=. B4957695 > * @summary URLJarFile.retrieve does not delete tmpFile on IOException > */ > > > From pavel.rappo at oracle.com Thu Oct 20 12:47:11 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 20 Oct 2016 13:47:11 +0100 Subject: RFR 8168405: Pending exceptions in java.base/windows/native Message-ID: Hello, Could you please review the following change for [1]? http://cr.openjdk.java.net/~prappo/8168405/webrev/ This change addresses some code paths in the native networking code for Windows operating system where thrown exceptions might be left unnoticed. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8168405 From christoph.langer at sap.com Thu Oct 20 13:03:07 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Oct 2016 13:03:07 +0000 Subject: RFR 8168405: Pending exceptions in java.base/windows/native In-Reply-To: References: Message-ID: <5e01d801ccde48a485d42b373c7ff55e@dewdfe13de07.global.corp.sap> Hi Pavel, overall this looks good. I've got a few minor remarks: 1. What about using the macro CHECK_NULL_RETURN in NetworkInterface_winXP.c? 2. in Java_java_net_TwoStacksPlainDatagramSocketImpl_peekData: You could move 1178 /* make sure receive() picks up the right fd */ 1179 (*env)->SetIntField(env, this, pdsi_fduseID, fduse); into the else branch above and set port to -1 in the n<0 branches. That way -1 will be returned always and the free(fullPacket) is also invoked if necessary with less lines of code :) But that's probably a matter of taste ;-) Best regards Christoph > -----Original Message----- > From: Pavel Rappo [mailto:pavel.rappo at oracle.com] > Sent: Donnerstag, 20. Oktober 2016 14:47 > To: OpenJDK Network Dev list > Subject: RFR 8168405: Pending exceptions in java.base/windows/native > > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8168405/webrev/ > > This change addresses some code paths in the native networking code for > Windows > operating system where thrown exceptions might be left unnoticed. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8168405 From pavel.rappo at oracle.com Thu Oct 20 13:11:28 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 20 Oct 2016 14:11:28 +0100 Subject: RFR 8168405: Pending exceptions in java.base/windows/native In-Reply-To: <5e01d801ccde48a485d42b373c7ff55e@dewdfe13de07.global.corp.sap> References: <5e01d801ccde48a485d42b373c7ff55e@dewdfe13de07.global.corp.sap> Message-ID: > On 20 Oct 2016, at 14:03, Langer, Christoph wrote: > > Hi Pavel, > > overall this looks good. I've got a few minor remarks: > > 1. What about using the macro CHECK_NULL_RETURN in NetworkInterface_winXP.c? > > 2. in Java_java_net_TwoStacksPlainDatagramSocketImpl_peekData: > > You could move > 1178 /* make sure receive() picks up the right fd */ > 1179 (*env)->SetIntField(env, this, pdsi_fduseID, fduse); > into the else branch above and set port to -1 in the n<0 branches. That way -1 will be returned always and the free(fullPacket) is also invoked if necessary with less lines of code :) But that's probably a matter of taste ;-) > > Best regards > Christoph Hi Christoph, Thanks a lot for looking into this! I would prefer to be a bit more explicit in both cases. And indeed I considered to do exactly what you described in the 2nd point, but then I saw this pattern in several different places (just grep it) in this file: if (packetBufferLen > MAX_BUFFER_LEN) { free(fullPacket); } So for consistency's sake maybe we should keep it as it is? I appreciate it looks a bit wordy. Thanks! From christoph.langer at sap.com Thu Oct 20 13:31:31 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Oct 2016 13:31:31 +0000 Subject: RFR 8168405: Pending exceptions in java.base/windows/native In-Reply-To: References: <5e01d801ccde48a485d42b373c7ff55e@dewdfe13de07.global.corp.sap> Message-ID: Hi Pavel, > > On 20 Oct 2016, at 14:03, Langer, Christoph > wrote: > > > > Hi Pavel, > > > > overall this looks good. I've got a few minor remarks: > > > > 1. What about using the macro CHECK_NULL_RETURN in > NetworkInterface_winXP.c? > > > > 2. in Java_java_net_TwoStacksPlainDatagramSocketImpl_peekData: > > > > You could move > > 1178 /* make sure receive() picks up the right fd */ > > 1179 (*env)->SetIntField(env, this, pdsi_fduseID, fduse); > > into the else branch above and set port to -1 in the n<0 branches. That way -1 > will be returned always and the free(fullPacket) is also invoked if necessary > with less lines of code :) But that's probably a matter of taste ;-) > > > > Best regards > > Christoph > > Hi Christoph, > > Thanks a lot for looking into this! I would prefer to be a bit more explicit in > both cases. And indeed I considered to do exactly what you described in the 2nd > point, but then I saw this pattern in several different places (just grep it) in > this file: > > if (packetBufferLen > MAX_BUFFER_LEN) { > free(fullPacket); > } > > So for consistency's sake maybe we should keep it as it is? I appreciate it > looks a bit wordy. > > Thanks! Ok, that's fine for me then. Unfortunately I'm no reviewer... Best regards Christoph From christoph.langer at sap.com Thu Oct 20 15:30:49 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 20 Oct 2016 15:30:49 +0000 Subject: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet In-Reply-To: <9B94F533-484F-4999-B597-AD797C8DAC55@oracle.com> References: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> <9B94F533-484F-4999-B597-AD797C8DAC55@oracle.com> Message-ID: Chris, I created a new version that addresses your points: http://cr.openjdk.java.net/~clanger/webrevs/8167481.1/ I reordered the headers according to your suggestions ( 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) generated headers ), added the @Native and removed the Windows stuff in net_util_md.h. To make reodering of system includes possible, I had to add back some system headers in a few places and could not always maintain the alphabetical order. I think you should run it through PRT and then hopefully give me your final blessing... Thanks & Best regards Christoph > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Dienstag, 18. Oktober 2016 20:56 > To: Langer, Christoph ; net-dev at openjdk.java.net > Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and includes for native > libnet > > Christoph, > > > On 17 Oct 2016, at 09:40, Langer, Christoph > wrote: > > ? > > Hi, > > > > as I already mentioned, here is another proposal for cleanup in libnet: > > https://bugs.openjdk.java.net/browse/JDK-8167481 > > http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ > > Overall, this looks good. Specific comments below ... > > > This time I touched the includes. Generally I reordered the includes to include > ?net_util.h? first, then any JNI includes, such as ?java_net_InetAddress.h? and > finally all standard header includes in alphabetical order. For platform specific > includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that > don?t seem to be necessary to get the respective file compiled. Is that the > correct approach that is desired? > > It is good to be consistent. My personal preference is to order the includes; > 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) > generated headers ( e.g. ?java_net_InetAddress.h? ). > > > To make this work, I had to remove the definitions ?IPv4? and ?IPv6? in > net_util.h and replace their usages with ?java_net_InetAddress_IPv4? resp. > ?java_net_InetAddress_IPv6? from JNI which seems to be the correct thing to > do anyway. > > Right. This is a good change. Trivially, and it is not strictly necessary but > good for readability, would be to add @Native to InetAddress.IPv4 and > InetAddress.IPv6. > > > For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 in > net_util_md.h and replaced all occurences with sockaddr_in6. It seems that the > capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft > runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even > older than Visual Studio 2003. So I?m wondering if I should remove the whole > section in windows net_util_md.h now (lines 47 ? 177)? > > I think it should be ok to remove this. > > > For Windows it seems that we can also completely get rid of > src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought by > the #include . Would you agree to that? > > Ok. > > > So far I successfully ran builds in my local environments for Windows, Linux, > AIX, Solaris and Apple. I?ve now added the changeset to our local regression > testing environment for OpenJDK. If the change is to your like, I would like to > ask you to also run it through JPRT to see if I missed some dependency. > > I ran your patch through our internal build and test system and there > are no surprises. > > -Chris. > > > Thanks and best regards > > Christoph From chris.hegarty at oracle.com Thu Oct 20 16:25:38 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Oct 2016 17:25:38 +0100 Subject: RFR 8168405: Pending exceptions in java.base/windows/native In-Reply-To: References: Message-ID: > On 20 Oct 2016, at 13:47, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8168405/webrev/ Thank you Pavel, this looks good. -Chris. > This change addresses some code paths in the native networking code for Windows > operating system where thrown exceptions might be left unnoticed. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8168405 > From volker.simonis at gmail.com Fri Oct 21 12:49:14 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Oct 2016 14:49:14 +0200 Subject: RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c Message-ID: Hi, can I please get a review for the following trivial fix: http://cr.openjdk.java.net/~simonis/webrevs/2016/8168471/ https://bugs.openjdk.java.net/browse/JDK-8168471 Change "8168405: Pending exceptions in java.base/windows/native" introduced the following non ANSI C compatible code for declaring a block-level variable ("jboolean ret"): } else /* AF_INET6 */ { int scope; iaObj = (*env)->NewObject(env, ia6_class, ia6_ctrID); if (iaObj == NULL) { return NULL; } jboolean ret = setInet6Address_ipaddress(env, iaObj, (jbyte *)&(addrs->addr.sa6.sin6_addr.s6_addr)); But ANSI C only allows the declaration of block local variable at the beginning of a block.Unfortunately some still very common compilers like Microsoft VS2010 and VS2012 still don't support this C99 feature :( Thank you and best regards, Volker From chris.hegarty at oracle.com Fri Oct 21 12:50:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 21 Oct 2016 13:50:56 +0100 Subject: RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c In-Reply-To: References: Message-ID: <5983799c-947f-839c-bf3d-67823b463b32@oracle.com> On 21/10/16 13:49, Volker Simonis wrote: > Hi, > > can I please get a review for the following trivial fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8168471/ > https://bugs.openjdk.java.net/browse/JDK-8168471 Thanks Volker. Reviewed. -Chris. > Change "8168405: Pending exceptions in java.base/windows/native" > introduced the following non ANSI C compatible code for declaring a > block-level variable ("jboolean ret"): > > } else /* AF_INET6 */ { > int scope; > iaObj = (*env)->NewObject(env, ia6_class, ia6_ctrID); > if (iaObj == NULL) { > return NULL; > } > jboolean ret = setInet6Address_ipaddress(env, iaObj, (jbyte > *)&(addrs->addr.sa6.sin6_addr.s6_addr)); > > But ANSI C only allows the declaration of block local variable at the > beginning of a block.Unfortunately some still very common compilers > like Microsoft VS2010 and VS2012 still don't support this C99 feature > :( > > Thank you and best regards, > Volker > From volker.simonis at gmail.com Fri Oct 21 12:53:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 21 Oct 2016 14:53:05 +0200 Subject: RFR(XXS): 8168471: Non ANSI C declaration of block local variable in NetworkInterface_winXP.c In-Reply-To: <5983799c-947f-839c-bf3d-67823b463b32@oracle.com> References: <5983799c-947f-839c-bf3d-67823b463b32@oracle.com> Message-ID: Thanks a lot Chris for the ultra-fast review! Regards, Volker On Fri, Oct 21, 2016 at 2:50 PM, Chris Hegarty wrote: > On 21/10/16 13:49, Volker Simonis wrote: >> >> Hi, >> >> can I please get a review for the following trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8168471/ >> https://bugs.openjdk.java.net/browse/JDK-8168471 > > > Thanks Volker. Reviewed. > > -Chris. > > >> Change "8168405: Pending exceptions in java.base/windows/native" >> introduced the following non ANSI C compatible code for declaring a >> block-level variable ("jboolean ret"): >> >> } else /* AF_INET6 */ { >> int scope; >> iaObj = (*env)->NewObject(env, ia6_class, ia6_ctrID); >> if (iaObj == NULL) { >> return NULL; >> } >> jboolean ret = setInet6Address_ipaddress(env, iaObj, (jbyte >> *)&(addrs->addr.sa6.sin6_addr.s6_addr)); >> >> But ANSI C only allows the declaration of block local variable at the >> beginning of a block.Unfortunately some still very common compilers >> like Microsoft VS2010 and VS2012 still don't support this C99 feature >> :( >> >> Thank you and best regards, >> Volker >> > From tobiast at google.com Mon Oct 24 19:33:33 2016 From: tobiast at google.com (Tobias Thierer) Date: Mon, 24 Oct 2016 20:33:33 +0100 Subject: HTTP client API Message-ID: Hi Michael and others - Thanks for publishing the latest HTTP client API docs (already slightly outdated again), as well as for publishing the current draft code in the sandbox repository! Below is some concrete feedback, questions and brainstorming on how to (a) increase the usefulness or (b) decrease the semantic weight of the API. Note that most of this is driven only by inspection of the API and some brief exploration of the implementation code, not (yet) by a substantial effort to write proof of concept client applications. I?d love if I could help make this API as useful to applications as possible, so I?d appreciate your feedback on how I can best do that and what the principles were that guided your design choices. 1.) The HttpRequest.BodyProcessor and HttpResponse.BodyProcessor abstractions seem particularly hard to grasp / have a high semantics weight. - What purpose does the abstraction of a BodyProcessor aim to fulfill beyond what the (simpler) abstraction of a Body could be? - Instead of describing the abstraction as a ?processor? of ByteBuffers / Java objects, wouldn?t it be simpler to say to say that request / response bodies are ByteBuffer / Java object sources / sinks? What is the advantage of the Publisher / Subscriber API over plain old InputStream / OutputStream based APIs? - The term ?processor? and the description of ?converting incoming buffers of data to some user-defined object type T? is especially confusing (increases the semantic weight of the abstraction) given that there is an implementation that discards all data (and its generic type is called U rather than T). A BodyProcessor that has no input but generates the digits of Pi is also conceivable. Perhaps call these BodySource / BodySink, ByteBufferPublisher / ByteBufferSubscriber, or just Body? - The fact that you felt the need to introduce an abstraction HttpResponse.BodyHandler whose name is similar to but whose semantics are different from HttpResponse.BodyProcessor is another indication that these concepts could be clarified and named better. - To explore how well the abstractions ?fit?, I played with some draft code implementing the API on top of another one; one thing I found particularly challenging was the control flow progression: HttpClient.send(request, bodyHandler) -> bodyProcessor = bodyHandler.apply(); // called by the library -> bodyProcessor.onSubscribe() / onNext() because it is push based and forces an application to relinquish control to the library rather than pulling data out of the library. Perhaps the Response BodyHandler abstraction could be eliminated altogether? For example, wouldn?t it be sufficient to abort downloading the body once an application thread has a chance to look at the Response object? Perhaps once a buffer is full, the download of the further response body could be delayed until a client asks for it? - What?s the purpose of HttpRequest.bodyProcessor()?s return type being an Optional (rather than BodyProcessor)? Why can?t this default to an empty body? - Naming inconsistency: HttpRequest.BodyProcessor.fromFile() vs. HttpResponse.BodyProcessor.asFile(). How about calling all of these of(), or alternatively renaming asFile() -> toFile() or toPath()? - asByteArrayConsumer(Consumer> consumer): Why is this an Optional? What logic decides whether an empty response body will be represented as a present byte[0] or an absent value? 2.) HttpHeaders: I love that there is a type for this abstraction! But: - Why is the type an interface rather than a concrete, final class? Since this is a pure value type, there doesn?t seem to be much point in allowing alternative implementations? - The documentation should probably specify what the methods do when name is not valid (according to RFC 7230 section 3.2?), or is null. - Do the methods other than map() really pull their weight (provide enough value relative to the semantic API weight that they introduce)? - firstValueAsLong() looks particularly suspect: why would anyone care particularly about long values? Especially since the current implementation seems to throw NumberFormatException rather than returning an empty Optional? 3.) Redirect - Stupid question: Should Redirect.SAME_PROTOCOL be called SAME_SCHEME (?scheme? is what the ?http? part is called in a URL)? I?m not sure which one is better. - I haven?t made up my mind about whether the existing choices are the right ones / sufficient. Perhaps if this class used the typesafe enum pattern from Effective Java 1st edition rather than being an actual enum, the API would maintain the option in a future version to allow client-configured Redirect policies, allowing Redirect for URLs as long as they are within the same host/domain? 4.) HttpClient.Version: - Why does a HttpClient need to commit to using one HTTP version or the other? What if an application wants to use HTTP/2 for those servers that support it, but fall back to HTTP/1.1 for those that don?t? 5.) CookieManager - Is there a common interface we could add without making the API much more complex to allow us both RFC 2965 (outdated, implemented by CookieManager) and RFC 6265 (new, real world, actually used) cookies? Needs prototyping. I think it?s likely we?ll be able to do something similar to OkHttp?s CookieJar which can be adapted to RFC 2965 - not 100%, but close enough that most implementations of CookieManager could be reused by the new HTTP API, while still taking advantage of RFC 6265 cookies. 6.) HttpClient.Executor - The documentation isn?t very clear about what tasks run on this executor and how a client can control HTTP traffic through a custom Executor instance. What power does the current executor() API provide to clients? Perhaps it would be simpler to omit this API altogether until the correct API becomes clearer? Thanks! Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Oct 25 12:55:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 25 Oct 2016 13:55:42 +0100 Subject: Temporarily remove java/net/httpclient from jdk_net test group Message-ID: Hi, There are some intermittent test failures in java/net/httpclient. Since development is ongoing over in the sandbox [1], then it is probably best to exclude these tests from the jdk_net test group, in the JDK 9 mainline, temporarily. diff -r a80fd00b0cd0 test/TEST.groups --- a/test/TEST.groups Tue Oct 25 10:31:49 2016 +0100 +++ b/test/TEST.groups Tue Oct 25 13:51:32 2016 +0100 @@ -158,6 +158,7 @@ jdk_net = \ java/net \ + -java/net/httpclient \ com/sun/net/httpserver \ sun/net \ jdk/net -Chris. [1] http://hg.openjdk.java.net/jdk9/sandbox/jdk/branches [http-client-branch] From Roger.Riggs at Oracle.com Tue Oct 25 13:20:18 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 25 Oct 2016 09:20:18 -0400 Subject: Temporarily remove java/net/httpclient from jdk_net test group In-Reply-To: References: Message-ID: <79be4d77-8cf5-6bb7-894b-b3c900ff33e5@Oracle.com> Hi Chris, Makes sense. Looks fine. Roger On 10/25/2016 8:55 AM, Chris Hegarty wrote: > Hi, > > There are some intermittent test failures in java/net/httpclient. Since development > is ongoing over in the sandbox [1], then it is probably best to exclude these tests > from the jdk_net test group, in the JDK 9 mainline, temporarily. > > diff -r a80fd00b0cd0 test/TEST.groups > --- a/test/TEST.groups Tue Oct 25 10:31:49 2016 +0100 > +++ b/test/TEST.groups Tue Oct 25 13:51:32 2016 +0100 > @@ -158,6 +158,7 @@ > > jdk_net = \ > java/net \ > + -java/net/httpclient \ > com/sun/net/httpserver \ > sun/net \ > jdk/net > > -Chris. > > [1] http://hg.openjdk.java.net/jdk9/sandbox/jdk/branches [http-client-branch] From joe.darcy at oracle.com Tue Oct 25 15:33:50 2016 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 25 Oct 2016 08:33:50 -0700 Subject: Temporarily remove java/net/httpclient from jdk_net test group In-Reply-To: References: Message-ID: <4ecb97ae-919b-3731-f3ed-b46723770d01@oracle.com> Looks fine Chris; thanks, -Joe On 10/25/2016 5:55 AM, Chris Hegarty wrote: > Hi, > > There are some intermittent test failures in java/net/httpclient. Since development > is ongoing over in the sandbox [1], then it is probably best to exclude these tests > from the jdk_net test group, in the JDK 9 mainline, temporarily. > > diff -r a80fd00b0cd0 test/TEST.groups > --- a/test/TEST.groups Tue Oct 25 10:31:49 2016 +0100 > +++ b/test/TEST.groups Tue Oct 25 13:51:32 2016 +0100 > @@ -158,6 +158,7 @@ > > jdk_net = \ > java/net \ > + -java/net/httpclient \ > com/sun/net/httpserver \ > sun/net \ > jdk/net > > -Chris. > > [1] http://hg.openjdk.java.net/jdk9/sandbox/jdk/branches [http-client-branch] From christoph.langer at sap.com Wed Oct 26 09:33:59 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Oct 2016 09:33:59 +0000 Subject: RFR(S): 8168771: Remove #ifdef AF_INET6 guards in libnet native coding Message-ID: <216abd94a00c435d922d3bdc8d3c6d59@DEROTE13DE08.global.corp.sap> Hi, please review the cleanup of "#ifdef AF_INET6" in libnet coding. I have opened a separate JIRA issue as requested This is a mailthread where it was already discussed: http://mail.openjdk.java.net/pipermail/net-dev/2016-October/010374.html Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8168771.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8168771 Thanks and best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Oct 26 13:38:30 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 26 Oct 2016 14:38:30 +0100 Subject: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet In-Reply-To: References: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> <9B94F533-484F-4999-B597-AD797C8DAC55@oracle.com> Message-ID: <9AD36BD0-E196-4E83-B70A-DC1DBAEA564B@oracle.com> > On 20 Oct 2016, at 16:30, Langer, Christoph wrote: > > Chris, > > I created a new version that addresses your points: > http://cr.openjdk.java.net/~clanger/webrevs/8167481.1/ Looks good to me. > I reordered the headers according to your suggestions ( 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) generated headers ), added the @Native and removed the Windows stuff in net_util_md.h. To make reodering of system includes possible, I had to add back some system headers in a few places and could not always maintain the alphabetical order. Ok, thanks. > I think you should run it through PRT and then hopefully give me your final blessing? I ran your patch through our internal build and test system, and there are no surprises. Consider is Reviewed, at least by me. -Chris. > Thanks & Best regards > Christoph > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Dienstag, 18. Oktober 2016 20:56 >> To: Langer, Christoph ; net-dev at openjdk.java.net >> Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and includes for native >> libnet >> >> Christoph, >> >>> On 17 Oct 2016, at 09:40, Langer, Christoph >> wrote: >>> ? >>> Hi, >>> >>> as I already mentioned, here is another proposal for cleanup in libnet: >>> https://bugs.openjdk.java.net/browse/JDK-8167481 >>> http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ >> >> Overall, this looks good. Specific comments below ... >> >>> This time I touched the includes. Generally I reordered the includes to include >> ?net_util.h? first, then any JNI includes, such as ?java_net_InetAddress.h? and >> finally all standard header includes in alphabetical order. For platform specific >> includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that >> don?t seem to be necessary to get the respective file compiled. Is that the >> correct approach that is desired? >> >> It is good to be consistent. My personal preference is to order the includes; >> 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) >> generated headers ( e.g. ?java_net_InetAddress.h? ). >> >>> To make this work, I had to remove the definitions ?IPv4? and ?IPv6? in >> net_util.h and replace their usages with ?java_net_InetAddress_IPv4? resp. >> ?java_net_InetAddress_IPv6? from JNI which seems to be the correct thing to >> do anyway. >> >> Right. This is a good change. Trivially, and it is not strictly necessary but >> good for readability, would be to add @Native to InetAddress.IPv4 and >> InetAddress.IPv6. >> >>> For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 in >> net_util_md.h and replaced all occurences with sockaddr_in6. It seems that the >> capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft >> runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even >> older than Visual Studio 2003. So I?m wondering if I should remove the whole >> section in windows net_util_md.h now (lines 47 ? 177)? >> >> I think it should be ok to remove this. >> >>> For Windows it seems that we can also completely get rid of >> src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought by >> the #include . Would you agree to that? >> >> Ok. >> >>> So far I successfully ran builds in my local environments for Windows, Linux, >> AIX, Solaris and Apple. I?ve now added the changeset to our local regression >> testing environment for OpenJDK. If the change is to your like, I would like to >> ask you to also run it through JPRT to see if I missed some dependency. >> >> I ran your patch through our internal build and test system and there >> are no surprises. >> >> -Chris. >> >>> Thanks and best regards >>> Christoph > From christoph.langer at sap.com Thu Oct 27 09:13:01 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 27 Oct 2016 09:13:01 +0000 Subject: Ping: RFR (M): 8167481: cleanup of headers and includes for native libnet In-Reply-To: <9AD36BD0-E196-4E83-B70A-DC1DBAEA564B@oracle.com> References: <52dc22365ade4bcca557c48e430e8052@DEWDFE13DE11.global.corp.sap> <9B94F533-484F-4999-B597-AD797C8DAC55@oracle.com> <9AD36BD0-E196-4E83-B70A-DC1DBAEA564B@oracle.com> Message-ID: <269eee76b2864f0094d734c03a9d3ffc@DEROTE13DE08.global.corp.sap> Thanks, Chris. I pushed it... > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Mittwoch, 26. Oktober 2016 15:39 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net > Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and includes for native > libnet > > > > On 20 Oct 2016, at 16:30, Langer, Christoph > wrote: > > > > Chris, > > > > I created a new version that addresses your points: > > http://cr.openjdk.java.net/~clanger/webrevs/8167481.1/ > > Looks good to me. > > > I reordered the headers according to your suggestions ( 1) system, 2) > platform specific includes, 3) JNI includes, and finally, 4) generated headers ), > added the @Native and removed the Windows stuff in net_util_md.h. To make > reodering of system includes possible, I had to add back some system headers > in a few places and could not always maintain the alphabetical order. > > Ok, thanks. > > > I think you should run it through PRT and then hopefully give me your final > blessing? > > I ran your patch through our internal build and test system, and there are no > surprises. Consider is Reviewed, at least by me. > > -Chris. > > > Thanks & Best regards > > Christoph > > > >> -----Original Message----- > >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > >> Sent: Dienstag, 18. Oktober 2016 20:56 > >> To: Langer, Christoph ; net- > dev at openjdk.java.net > >> Subject: Re: Ping: RFR (M): 8167481: cleanup of headers and includes for > native > >> libnet > >> > >> Christoph, > >> > >>> On 17 Oct 2016, at 09:40, Langer, Christoph > >> wrote: > >>> ? > >>> Hi, > >>> > >>> as I already mentioned, here is another proposal for cleanup in libnet: > >>> https://bugs.openjdk.java.net/browse/JDK-8167481 > >>> http://cr.openjdk.java.net/~clanger/webrevs/8167481.0/ > >> > >> Overall, this looks good. Specific comments below ... > >> > >>> This time I touched the includes. Generally I reordered the includes to > include > >> ?net_util.h? first, then any JNI includes, such as ?java_net_InetAddress.h? > and > >> finally all standard header includes in alphabetical order. For platform > specific > >> includes, I use the order Linux, AIX, Solaris, BSD. I removed all includes that > >> don?t seem to be necessary to get the respective file compiled. Is that the > >> correct approach that is desired? > >> > >> It is good to be consistent. My personal preference is to order the includes; > >> 1) system, 2) platform specific includes, 3) JNI includes, and finally, 4) > >> generated headers ( e.g. ?java_net_InetAddress.h? ). > >> > >>> To make this work, I had to remove the definitions ?IPv4? and ?IPv6? in > >> net_util.h and replace their usages with ?java_net_InetAddress_IPv4? resp. > >> ?java_net_InetAddress_IPv6? from JNI which seems to be the correct thing > to > >> do anyway. > >> > >> Right. This is a good change. Trivially, and it is not strictly necessary but > >> good for readability, would be to add @Native to InetAddress.IPv4 and > >> InetAddress.IPv6. > >> > >>> For Windows I also cleaned up (removed) the definition of SOCKADDR_IN6 > in > >> net_util_md.h and replaced all occurences with sockaddr_in6. It seems that > the > >> capital letters version SOCKADDR_IN6 is a remainder of a very old Microsoft > >> runtime (_MSC_VER < 1310) which corresponds to MSVC 7.0, which is even > >> older than Visual Studio 2003. So I?m wondering if I should remove the > whole > >> section in windows net_util_md.h now (lines 47 ? 177)? > >> > >> I think it should be ok to remove this. > >> > >>> For Windows it seems that we can also completely get rid of > >> src/java.base/windows/native/libnet/icmp.h as the icmp stuff is all brought > by > >> the #include . Would you agree to that? > >> > >> Ok. > >> > >>> So far I successfully ran builds in my local environments for Windows, > Linux, > >> AIX, Solaris and Apple. I?ve now added the changeset to our local regression > >> testing environment for OpenJDK. If the change is to your like, I would like to > >> ask you to also run it through JPRT to see if I missed some dependency. > >> > >> I ran your patch through our internal build and test system and there > >> are no surprises. > >> > >> -Chris. > >> > >>> Thanks and best regards > >>> Christoph > > From anthony.vanelverdinghe at gmail.com Thu Oct 27 18:19:25 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Thu, 27 Oct 2016 20:19:25 +0200 Subject: HTTP client API In-Reply-To: References: Message-ID: <70e093fb-5dd1-b353-c4c9-2fe50a5f7888@gmail.com> Hi Tobias As far as I know, the latest published Javadoc is at [1] (which was linked to in [2]). However, this Javadoc doesn't exactly match the current code either. Below are some quick replies to some of your feedback. 1.) > What is the advantage of the Publisher / Subscriber API over plain old InputStream / OutputStream based APIs? InputStream / OutputStream are blocking APIs, whereas Publisher / Subscriber are part of the Flow API, which corresponds to the Reactive Streams specification [3]. > there is an implementation that discards all data [...] (and its generic type is called U rather than T) The generic type is called U to avoid shadowing the type parameter in the enclosing HttpResponse.BodyProcessor > one thing I found particularly challenging was the control flow progression [...] because it is push based and forces an application to relinquish control to the library rather than pulling data out of the library. The application is still in control by means of its Flow.Subscription (see Flow.Subscriber::onSubscribe), isn't it? > asByteArrayConsumer(Consumer> consumer): Why is this an Optional? What logic decides whether an empty response body will be represented as a present byte[0] or an absent value? As the Javadoc says, it's an Optional to be able to mark the end of the body. In case of an empty response body, the Consumer will therefore receive an Optional.empty() value. 2.) what happens when name is null, is specified by the following note in the package Javadoc: "Unless otherwise stated, null parameter values will cause methods of all classes in this package to throw NullPointerException." 3.) allowing custom redirection policies was brought up before [4][5], proposing that a redirection policy would simply be a BiFunction>. Besides, analog to e.g. java.nio.file.StandardOpenOption, there would also be a StandardRedirectionPolicy enum [6]. 4.) it doesn't, as is specified in HttpClient.Builder::version 5.) this was brought up in [7], and was addressed, I believe, in the latest API [1] by replacing CookieManager with java.net.CookieHandler. However, this change isn't in the current code (yet?). 6.) I'd assume the Executor is used to handle asynchronous requests (HttpClient::sendAsync in [1]). So by using a fixed thread pool, one can control the maximum number of concurrent requests. Hope this helps, Anthony [1] http://cr.openjdk.java.net/~michaelm/httpclient/api.1/ [2] http://mail.openjdk.java.net/pipermail/net-dev/2016-September/010238.html [3] http://www.reactive-streams.org/ [4] http://mail.openjdk.java.net/pipermail/net-dev/2016-February/009547.html [5] http://mail.openjdk.java.net/pipermail/net-dev/2016-March/009608.html [6] http://jep110-anthonyvdotbe.rhcloud.com/api/jep110/StandardRedirectionPolicy.html [7] http://mail.openjdk.java.net/pipermail/net-dev/2016-August/010187.html On 24/10/2016 21:33, Tobias Thierer wrote: > > Hi Michael and others - > > > Thanks for publishing the latest HTTP client API docs > (already > slightly outdated again), as well as for publishing the current draft > code in the sandbox repository! > > > Below is some concrete feedback, questions and brainstorming on how to > > (a) increase the usefulness or > > (b) decrease the semantic weight > > of the API. Note that most of this is driven only by inspection of the > API and some brief exploration of the implementation code, not (yet) > by a substantial effort to write proof of concept client applications. > I?d love if I could help make this API as useful to applications as > possible, so I?d appreciate your feedback on how I can best do that > and what the principles were that guided your design choices. > > > 1.) The HttpRequest.BodyProcessor > and > HttpResponse.BodyProcessor > abstractions > seem particularly hard to grasp / have a high semantics weight. > > * > > What purpose does the abstraction of a BodyProcessoraim to fulfill > beyond what the (simpler) abstraction of a Bodycould be? > > o > > Instead of describing the abstraction as a ?processor? of > ByteBuffers / Java objects, wouldn?t it be simpler to say to > say that request / response bodiesare ByteBuffer / Java object > sources/ sinks? What is the advantage of the > Publisher / Subscriber API over plain > old InputStream / OutputStream based APIs? > > o > > The term ?processor? and the description of ?converting > incoming buffers of data to some user-defined object type T? > is especially confusing (increases the semantic weight of the > abstraction) given that there is an implementation that > discards all data > (and > its generic type is called Urather than T). A BodyProcessor > that has no input but generates the digits of Pi is also > conceivable. Perhaps call these BodySource / BodySink, > ByteBufferPublisher / ByteBufferSubscriber, or just Body? > > o > > The fact that you felt the need to introduce an abstraction > HttpResponse.BodyHandler whose name is similar to but whose > semantics are different from HttpResponse.BodyProcessor is > another indication that these concepts could be clarified and > named better. > > o > > To explore how well the abstractions ?fit?, I played with some > draft code implementing the API on top of another one; one > thing I found particularly challenging was the control flow > progression:HttpClient.send(request, bodyHandler)-> > bodyProcessor = bodyHandler.apply(); // called by the > library-> bodyProcessor.onSubscribe() / onNext()because it is > push based and forces an application to relinquish control to > the library rather than pulling data out of the > library.Perhaps the Response BodyHandler abstraction could be > eliminated altogether? For example, wouldn?t it be sufficient > to abort downloading the body once an application thread has a > chance to look at the Response object? Perhaps once a buffer > is full, the download of the further response body could be > delayed until a client asks for it? > > o > > What?s the purpose of HttpRequest.bodyProcessor()?s return > type being an Optional (rather than > BodyProcessor)? Why can?t this default to an empty body? > > o > > Naming inconsistency: HttpRequest.BodyProcessor.fromFile() vs. > HttpResponse.BodyProcessor.asFile(). How about calling all of > these of(), or alternatively renaming asFile() -> toFile() or > toPath()? > > o > > asByteArrayConsumer(Consumer> consumer): Why > is this an Optional? What logic decides whether an empty > response body will be represented as a present byte[0] or an > absent value? > > > 2.) HttpHeaders: I love that there is a type for this abstraction! But: > > * > > Why is the type an interface rather than a concrete, final class? > Since this is a pure value type, there doesn?t seem to be much > point in allowing alternative implementations? > > * > > The documentation should probably specify what the methods do when > nameis not valid (according to RFC 7230 section 3.2?), or is null. > > * > > Do the methods other than map() really pull their weight (provide > enough value relative to the semantic API weight that they introduce)? > > o > > firstValueAsLong() looks particularly suspect: why would > anyone care particularly about long values? Especiallysince > the current implementation seems to throw > NumberFormatException rather than returning an empty Optional? > > > 3.) Redirect > > * > > Stupid question: Should Redirect.SAME_PROTOCOL be called > SAME_SCHEME (?scheme? is what the ?http? part is called in a URL)? > I?m not sure which one is better. > > * > > I haven?t made up my mind about whether the existing choices are > the right ones / sufficient. Perhaps if this class used the > typesafe enum pattern from Effective Java 1st edition rather than > being an actual enum, the API would maintain the option in a > future version to allow client-configured Redirect policies, > allowing Redirect for URLs as long as they are within the same > host/domain? > > > 4.) HttpClient.Version: > > * > > Why does a HttpClient need to commit to using one HTTP version or > the other? What if an application wants to use HTTP/2 for those > servers that support it, but fall back to HTTP/1.1 for those that > don?t? > > > 5.) CookieManager > > * > > Is there a common interface we could add without making the API > much more complex to allow us both RFC 2965 (outdated, implemented > by CookieManager) and RFC 6265 (new, real world, actually used) > cookies? Needs prototyping. I think it?s likely we?ll be able to > do something similar to OkHttp?s CookieJar > which > can be adapted to RFC 2965 - not 100%, but close enough that most > implementations of CookieManager could be reused by the new HTTP > API, while still taking advantage of RFC 6265 cookies. > > > 6.) HttpClient.Executor > > * The documentation isn?t very clear about what tasks run on this > executor and how a client can control HTTP traffic through a > custom Executor instance. What power does the current executor() > API provide to clients? Perhaps it would be simpler to omit this > API altogether until the correct API becomes clearer? > > Thanks! > Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.x.mcmahon at oracle.com Fri Oct 28 11:28:38 2016 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 28 Oct 2016 12:28:38 +0100 Subject: HTTP client API In-Reply-To: References: Message-ID: <58133666.4030507@oracle.com> Hi Tobias Thanks for the feedback (and thanks to Anthony for answering some of the questions) My thoughts are below. On 24/10/2016, 20:33, Tobias Thierer wrote: > > Hi Michael and others - > > > Thanks for publishing the latest HTTP client API docs > (already > slightly outdated again), as well as for publishing the current draft > code in the sandbox repository! > > > Below is some concrete feedback, questions and brainstorming on how to > > (a) increase the usefulness or > > (b) decrease the semantic weight > > of the API. Note that most of this is driven only by inspection of the > API and some brief exploration of the implementation code, not (yet) > by a substantial effort to write proof of concept client applications. > I?d love if I could help make this API as useful to applications as > possible, so I?d appreciate your feedback on how I can best do that > and what the principles were that guided your design choices. > > > 1.) The HttpRequest.BodyProcessor > and > HttpResponse.BodyProcessor > abstractions > seem particularly hard to grasp / have a high semantics weight. > > * > > What purpose does the abstraction of a BodyProcessoraim to fulfill > beyond what the (simpler) abstraction of a Bodycould be? > > o > > Instead of describing the abstraction as a ?processor? of > ByteBuffers / Java objects, wouldn?t it be simpler to say to > say that request / response bodiesare ByteBuffer / Java object > sources/ sinks? What is the advantage of the > Publisher / Subscriber API over plain > old InputStream / OutputStream based APIs? > The intention behind those interfaces is primarily to provide a conversion between ByteBuffers and higher level objects that users are interested in. So, HttpRequest.BodyProcessor generates ByteBuffers for output and HttpResponse.ByteBuffer consumes them on input. For response bodies, there is this additional implicit requirement of needing to do something with the incoming data and that is why the option of discarding it exists (the details of that API are certainly open to discussion) On Publisher/Subscriber (Flow) versus InputStream/OutputStream, we wanted a non blocking API and had originally defined something that was quite similar to the asynchronous model used by Flow, but the Flow types have a nice mechanism for managing flow control asynchronously. So, it made sense to use the standard API. > o > > The term ?processor? and the description of ?converting > incoming buffers of data to some user-defined object type T? > is especially confusing (increases the semantic weight of the > abstraction) given that there is an implementation that > discards all data > (and > its generic type is called Urather than T). A BodyProcessor > that has no input but generates the digits of Pi is also > conceivable. Perhaps call these BodySource / BodySink, > ByteBufferPublisher / ByteBufferSubscriber, or just Body? > > o > > The fact that you felt the need to introduce an abstraction > HttpResponse.BodyHandler whose name is similar to but whose > semantics are different from HttpResponse.BodyProcessor is > another indication that these concepts could be clarified and > named better. > We're certainly open to suggestions for improved names, but I think it is useful to have a way to explicitly discard a response body, especially since HTTP/2 has an efficient way to do that. I am looking at the moment at simplifications of the server push API, and it will be helpful if the request and response body processor types have shorter names, to help with that. So, I'll take a look at the possibility of using something using BodySource/BodySink. > o > > To explore how well the abstractions ?fit?, I played with some > draft code implementing the API on top of another one; one > thing I found particularly challenging was the control flow > progression: > HttpClient.send(request, bodyHandler) > -> bodyProcessor = bodyHandler.apply(); // called by the library > -> bodyProcessor.onSubscribe() / onNext() > because it is push based and forces an application to > relinquish control to the library rather than pulling data out > of the library. > Perhaps the Response BodyHandler abstraction could be > eliminated altogether? For example, wouldn?t it be sufficient > to abort downloading the body once an application thread has a > chance to look at the Response object? Perhaps once a buffer > is full, the download of the further response body could be > delayed until a client asks for it? > On the question of push versus pull, there seems to be differing philosophies around this, but actually the publish/subscribe model provided by the Flow types has characteristics of both push and pull. It is primarily push() as in Subscriber.onNext() delivers the next buffer to the subscriber. But, the subscriber can effectively control it through the Subscription object. There are other benefits to having the body available synchronously with the rest of the response object and it is still possible to implement arbitrary streaming of response body data without having to buffer it. A while ago I prototyped a response processor which delivers the body through an InputStream. > o > > What?s the purpose of HttpRequest.bodyProcessor()?s return > type being an Optional (rather than > BodyProcessor)? Why can?t this default to an empty body? > I think Anthony answered this > > o > > Naming inconsistency: HttpRequest.BodyProcessor.fromFile() vs. > HttpResponse.BodyProcessor.asFile(). How about calling all of > these of(), or alternatively renaming asFile() -> toFile() or > toPath()? > Probably should consider this question after any renaming of the response processor types themselves. > o > > asByteArrayConsumer(Consumer> consumer): Why > is this an Optional? What logic decides whether an empty > response body will be represented as a present byte[0] or an > absent value? > > I think Anthony answered this > 2.) HttpHeaders: I love that there is a type for this abstraction! But: > > * > > Why is the type an interface rather than a concrete, final class? > Since this is a pure value type, there doesn?t seem to be much > point in allowing alternative implementations? > You could conceive of different implementations, with different tradeoffs between parsing early or lazily for instance. > * > > The documentation should probably specify what the methods do when > nameis not valid (according to RFC 7230 section 3.2?), or is null. > > * > > Do the methods other than map() really pull their weight (provide > enough value relative to the semantic API weight that they introduce)? > > o > > firstValueAsLong() looks particularly suspect: why would > anyone care particularly about long values? Especiallysince > the current implementation seems to throw > NumberFormatException rather than returning an empty Optional? > > Numeric header values would be fairly common I think. Long was just chosen as the widest possible integer type. NumberFormatException is only thrown if the value is present but can't be parsed as a number. > > 3.) Redirect > > * > > Stupid question: Should Redirect.SAME_PROTOCOL be called > SAME_SCHEME (?scheme? is what the ?http? part is called in a URL)? > I?m not sure which one is better. > I'll consider that suggestion. > > * > > I haven?t made up my mind about whether the existing choices are > the right ones / sufficient. Perhaps if this class used the > typesafe enum pattern from Effective Java 1st edition rather than > being an actual enum, the API would maintain the option in a > future version to allow client-configured Redirect policies, > allowing Redirect for URLs as long as they are within the same > host/domain? > > As Anthony mentioned, there was a more complicated API originally, but it was felt to be too complicated, which was why we settled on enums (which can be extended in future). > 4.) HttpClient.Version: > > * > > Why does a HttpClient need to commit to using one HTTP version or > the other? What if an application wants to use HTTP/2 for those > servers that support it, but fall back to HTTP/1.1 for those that > don?t? > > Answered. > > 5.) CookieManager > > * > > Is there a common interface we could add without making the API > much more complex to allow us both RFC 2965 (outdated, implemented > by CookieManager) and RFC 6265 (new, real world, actually used) > cookies? Needs prototyping. I think it?s likely we?ll be able to > do something similar to OkHttp?s CookieJar > which > can be adapted to RFC 2965 - not 100%, but close enough that most > implementations of CookieManager could be reused by the new HTTP > API, while still taking advantage of RFC 6265 cookies. > > One suggestion has been to use the low-level CookieHandler API. But, another option would be just to evolve CookieManager to the latest RFCs, which sounds a lot like what you are suggesting. > 6.) HttpClient.Executor > > * The documentation isn?t very clear about what tasks run on this > executor and how a client can control HTTP traffic through a > custom Executor instance. What power does the current executor() > API provide to clients? Perhaps it would be simpler to omit this > API altogether until the correct API becomes clearer? > > Basically, the main lever that an Executor offers to clients is the choice of one of the existing ExecutorService implementations provided by java.util.concurrent.Executors which are various types of thread pools (or a customized one). So, you can choose fixed size pools, or variable sized pools for example. The spec is deliberately vague on the allocation of tasks to threads, to allow for different implementations, with differing degrees of blocking/non blocking behavior. I hope to put out a new version of the API very soon, addressing some of the points I mention above. Thanks, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobiast at google.com Mon Oct 31 18:13:04 2016 From: tobiast at google.com (Tobias Thierer) Date: Mon, 31 Oct 2016 18:13:04 +0000 Subject: HTTP client API In-Reply-To: <58133666.4030507@oracle.com> References: <58133666.4030507@oracle.com> Message-ID: Hi Michael - thanks a lot for your response! Further comments below. How would you rank simplicity, versatility and performance as goals for the HTTP Client API? For example the blocking vs. non-blocking API choices will largely depend on trade-offs, so I'd like to understand the target applications and requirements that these trade-offs were based on. On Fri, Oct 28, 2016 at 12:28 PM, Michael McMahon < michael.x.mcmahon at oracle.com> wrote: > > The intention behind those interfaces is primarily to provide a conversion > between ByteBuffers and higher level objects that users > are interested in. So, HttpRequest.BodyProcessor generates ByteBuffers for > output and HttpResponse.ByteBuffer consumes them > on input. For response bodies, there is this additional implicit > requirement of needing to do something with the incoming data > and that is why the option of discarding it exists (the details of that > API are certainly open to discussion) > > On Publisher/Subscriber (Flow) versus InputStream/OutputStream, we wanted > a non blocking API > I can understand the desire to have a non blocking API, especially if performance is seen as more important for the API than usability. Cronet (the Chromium networking stack) API [documentation ] has a UrlRequest.read(ByteBuffer) <-> callback.onReadCompleted(UrlRequest, UrlResponseInfo, ByteBuffer) call cycle that is not too different from OpenJDK 9 HTTP client's subscription.request(1) <-> BodyProcessor.onNext(ByteBuffer) so the general idea is shared by others (I'm meeting with some Cronet folks later this week so I hope to gather their input / views soon). Note that in Cronet, the ByteBuffer is provided as part of each call requesting more data, whereas in OpenJDK 9 it's returned once BodyProcessor.getBuffer(). At the same time, the first and third goal mentioned in JEP 110 are - *Must be easy to use for common cases, including a simple blocking mode.* - *A simple and concise API which caters for 80-90% of application needs. * Blocking, pull-based APIs tend to be simpler to use because (a) one can just step through a for loop in a debugger rather than needing breakpoints, and (b) state can be held on the stack rather than in fields [see related blog post ], so I'm struggling to follow the trade-offs here. Obviously, blocking APIs have some disadvantages as well - e.g. context switching overhead in the case of separate Threads per request. Is there any place other than JEP 110 where I could read up on principles or target applications that drove the trade-offs for this API? A concrete example that I tried to prototype was reading an image file header & body from the network, potentially aborting the request depending on some metadata in the file header; using the OpenJDK 9 HTTP client API, this involved a ton of boilerplate. Part of the boilerplate was because I wasn't sure if onNext() might get a partially filled ByteBuffer that might cut off the image file header or even an individual int32 value in that header. Is it guaranteed that the ByteBuffer returned by BodyProcessor.getBuffer will be full on each call to onNext(ByteBuffer), except possibly the last? If not, perhaps it should be guaranteed? Related to this, it appears that the documentation for Subscription.request(long n) specifies that *n* specifically *denotes the number of future calls* to onNext() . If this wasn't the case, BodyProcessor could have defined *n* to refer to a number of bytes (delivered as a single onNext() call if they fit into the supplied ByteBuffer), which might have been a really neat way for the application to control the sizes of chunks that it gets passed. For example, an application might want to get the file header in one go, and then afterwards process some fixed size data record for each call. Oh well. Do you happen to have an idea for how the application could be more in control of the chunk sizes? > and had originally defined > something that was quite similar to the asynchronous model used by Flow, > but the Flow types have a nice mechanism for > managing flow control asynchronously. So, it made sense to use the > standard API. > Regarding managing flow control, I assume you're referring to subscription.request() which I assume is tied to WINDOW_UPDATE frames in HTTP 2? Also, I assume that Subscription.cancel() will result in a RST_STREAM frame being sent to the server, is that correct? Is there a recommended way for an application to limit stream concurrency (RFC 7540 section 5.1.2 )? Example use case: An application that loads and decodes .jpeg images from the network might be limited by how many decompressed images it can hold in memory at a time (the application may want to re-compress the images in a different format, e.g. for file format conversion or to send them to the GPU in ETC2 texture compression format). Would such an application manually maintain a limited set of "active" streams, making sure to start calling request() only for those streams that have become active? (With a blocking API, an application could simply use a fixed-size thread pool, or could use a Semaphore to guard access to a limited resource, such as memory). We're certainly open to suggestions for improved names, but I think it is > useful to have a way to explicitly discard a response body, especially > since HTTP/2 has an efficient way to do that. > Why can't the response body instead be discarded by calling subscription.cancel() during the call to onSubscribe() (before the first ByteBuffer of the body data has been delivered)? On the question of push versus pull, there seems to be differing > philosophies around this, but > actually the publish/subscribe model provided by the Flow types has > characteristics of both push and pull. > It is primarily push() as in Subscriber.onNext() delivers the next buffer > to the subscriber. But, the subscriber > can effectively control it through the Subscription object. > What does "effectively control" means? As far as I can see, the subscriber can stop calls temporarily by not calling request(), but e.g. it can not request a minimum number of bytes to deliver (if available before EOF) on the next call. Is that correct or am I missing something? (See above question about whether ByteBuffers are completely filled). There are other benefits to having the body available synchronously with > the rest of the response object > and it is still possible to implement arbitrary streaming of response body > data without having to buffer it. > A while ago I prototyped a response processor which delivers the body > through an InputStream. > What's the reason that implementation got dropped? FWIW, I suspect that a lot of applications will be tempted to use HttpResponse.asByteArray().getBody(); if this happens, it'll be strictly worse than a potential HttpResponse.asInputStream() because - it holds the entire response body in memory as a byte[], and - processing only starts after the last byte of the response is received from the network (this means that the request can't be aborted part way through) 2.) HttpHeaders: I love that there is a type for this abstraction! But: > > - > > Why is the type an interface rather than a concrete, final class? > Since this is a pure value type, there doesn?t seem to be much point in > allowing alternative implementations? > > You could conceive of different implementations, with different tradeoffs > between parsing early or lazily for instance. > What parsing are you referring to? I don't see any parsing logic in HttpHeadersImpl other than in firstValueAsLong. It does however have logic that alternative implementations could get wrong / be inconsistent with, such as - whether to use case insensitive comparison for header names - whether the Map returned from map() is unmodifiable - whether the List returned by allValues() is unmodifiable (it is modifiable in the current implementation, but I think that's a bug) - the behavior of firstValueAsLong when the value exists but is not parseable as a long Have you considered making HttpHeaders immutable and adding a Builder implementation? That would make it thread safe at a small cost to the semantic weight of the API. > - > > Do the methods other than map() really pull their weight > - > > (provide enough value relative to the semantic API weight that they > introduce)? > - > > firstValueAsLong() looks particularly suspect: why would anyone > care particularly about long values? Especially since the current > implementation seems to throw NumberFormatException rather than returning > an empty Optional? > > > Numeric header values would be fairly common I think. Long was just chosen > as the widest possible integer type. > NumberFormatException is only thrown if the value is present but can't be > parsed as a number. > But then you'd have to document that NFE is thrown, which an application would have been much less likely to miss if they had called Long.valueOf() themselves. It's also not clear that throwing NFE, rather than returning an empty Optional, is the behavior that most applications prefer. These methods seem to add semantic weight to the API for very little benefit. Perhaps it'd be better to leave them out, but add them in a future revision of the API if it turns out that a lot of applications duplicate exactly this logic? > - > > I haven?t made up my mind about whether the existing choices are the > right ones / sufficient. Perhaps if this class used the typesafe enum > pattern from Effective Java 1st edition rather than being an actual enum, > the API would maintain the option in a future version to allow > client-configured Redirect policies, allowing Redirect for URLs as long as > they are within the same host/domain? > > > As Anthony mentioned, there was a more complicated API originally, but it > was felt to be too complicated, which > was why we settled on enums (which can be extended in future). > The choice of enums limits the versatility because all enum instances need to be known at compile time; for example, it'd be impossible to provide a Redirect policy that allows redirects to a given set of hosts. The only benefit I can see from using specifically an enum class is that this gives us a serialization format for free. But a conversion to/from String values for the standard policy instances (via a valueOf(String) method or similar) would offer the same at a fairly small cost of semantic weight. For example, doesn't the existence of the convenience method HttpHeaders.firstValueAsLong() have a much smaller benefit, but similar semantic weight, to e.g. a potential non-enum Redirect.valueOf() method (and even so, that method could be left to a future API version)? > 4.) HttpClient.Version: > > - > > Why does a HttpClient need to commit to using one HTTP version or the > other? What if an application wants to use HTTP/2 for those servers that > support it, but fall back to HTTP/1.1 for those that don?t? > > > Answered. > Given that HttpClientBuilder.version(Version) does not actually restrict the client to only that version, should it perhaps be called setMaximumVersion(Version), or changed to enableVersion(Version) / disableVersion(Version), or similar? > 5.) CookieManager > > - > > Is there a common interface we could add without making the API much > more complex to allow us both RFC 2965 (outdated, implemented by > CookieManager) and RFC 6265 (new, real world, actually used) cookies? Needs > prototyping. I think it?s likely we?ll be able to do something similar to OkHttp?s > CookieJar > > which can be adapted to RFC 2965 - not 100%, but close enough that most > implementations of CookieManager could be reused by the new HTTP API, while > still taking advantage of RFC 6265 cookies. > > > One suggestion has been to use the low-level CookieHandler API. But, > another option would be just to > evolve CookieManager to the latest RFCs, which sounds a lot like what you > are suggesting. > Not exactly what I was suggesting, but similar and might work. For what it's worth, even CookieHandler mentions "Cookie2" headers in the documentation so this would need to be changed and the backwards compatibility risk would need to be estimated. For reference, RFC 7540 (HTTP 2) normative [COOKIE] reference is to the (new) cookie RFC 6265 which no longer has Cookie2 / Set-Cookie2 headers. Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobiast at google.com Mon Oct 31 20:25:09 2016 From: tobiast at google.com (Tobias Thierer) Date: Mon, 31 Oct 2016 20:25:09 +0000 Subject: HTTP client API In-Reply-To: <70e093fb-5dd1-b353-c4c9-2fe50a5f7888@gmail.com> References: <70e093fb-5dd1-b353-c4c9-2fe50a5f7888@gmail.com> Message-ID: On Thu, Oct 27, 2016 at 7:19 PM, Anthony Vanelverdinghe < anthony.vanelverdinghe at gmail.com> wrote: As far as I know, the latest published Javadoc is at [1] (which was linked > to in [2]). However, this Javadoc doesn't exactly match the current code > either. > Thanks for the updated links and for your responses below! Further comments inline below - I'm keeping some bits brief since I just responded to Michael's email as well, I might write more later. > one thing I found particularly challenging was the control flow > progression [...] because it is push based and forces an application to > relinquish control to the library rather than pulling data out of the > library. > The application is still in control by means of its Flow.Subscription (see > Flow.Subscriber::onSubscribe), isn't it? > When I said "*in control*", I meant that the flow of execution is controlled by loops, if statements etc. in application code, as opposed to the application needing to *react* to the library deciding to call some callbacks. The former API tends to be easier to use and debug, the latter might allow better performance (throughput/latency). How are you driving the trade-offs in this area? > > asByteArrayConsumer(Consumer> consumer): Why is this > an Optional? What logic decides whether an empty response body will be > represented as a present byte[0] or an absent value? > As the Javadoc says, it's an Optional to be able to mark the end of the > body. In case of an empty response body, the Consumer will therefore > receive an Optional.empty() value. > How is it easier for an application to handle the special value of an Optional.empty() to signify the end of data than it would be to handle null? It seems like the absent/empty Optional just becomes another kind of null here - you're just replacing NullPointerException with NoSuchElementException. 2.) what happens when name is null, is specified by the following note in > the package Javadoc: "Unless otherwise stated, null parameter values will > cause methods of all classes in this package to throw NullPointerException." > Ah, thanks, I had missed that. 3.) allowing custom redirection policies was brought up before [4][5], > proposing that a redirection policy would simply be a > BiFunction>. Besides, analog > to e.g. java.nio.file.StandardOpenOption, there would also be a > StandardRedirectionPolicy enum [6]. > That makes sense. Has anyone considered an abstraction along the lines of OkHttp's Interceptor ? I don't know how well they would interact with the Flow API, but it's a simple API with versatile uses such as: - redirects (potentially replacing the Redirect abstraction) - early abort based on headers or response code (potentially replacing the BodyHandler abstraction) - logging (potentially offering additional functionality) - ... ? 4.) it doesn't, as is specified in HttpClient.Builder::version > Per my other response to Michael just now: Given that HttpClientBuilder.version(Version) does not actually restrict the client to only that version, should it perhaps be called setMaximumVersion(Version), or changed to enableVersion(Version) / disableVersion(Version), or similar? 5.) this was brought up in [7], and was addressed, I believe, in the latest > API [1] by replacing CookieManager with java.net.CookieHandler. However, > this change isn't in the current code (yet?). > Ah, interesting. I look forward to seeing if CookieHandler can be tweaked to allow RFC 6265 cookies. Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: