Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

On 10 May 2016, at 20:52, e...@zusammenkunft.net wrote: > Hello, > > Love it. Yes, this is along the same lines as I was thinking. > Not sure about two things, first of all if there are more test cases > (especially assertions) needed and Right. Maybe a new test that, 1) runs in all three

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

gt; Best regards > Christoph > > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Donnerstag, 12. Mai 2016 12:43 >> To: Langer, Christoph <christoph.lan...@sap.com> >> Cc: Alan Bateman <alan.bate...@oracle.co

JDK-8148424 Support IPv6-only Unix environments

Martin, Promoted by some other changes that are going on, I stumbled across your proposal for 8148424: "Support IPv6-only Unix environments” [1][2][3]. I think the changes are good. I rebased them against the latest source in jdk9/dev. http://cr.openjdk.java.net/~chegar/8148424/ I put the

Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

properties are checked only once, at startup. If you agree, can you fold it into your patch, and generate a changeset. -Chris. > Thanks, > Vyom > > > On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote: >> Vyom, >> >> On 13/05/16 08:23, vyom wro

Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

d the changes as you suggested. Thanks. The updated webrev look good. -Chris. > Thanks, > Vyom > > > On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: >> On 17 May 2016, at 10:48, vyom <vyom.tew...@oracle.com> wrote: >> >>> Hi Chris, >>> &g

[OFFLIST] Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

you suggested. > > Thanks, > Vyom > > > On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: >> On 17 May 2016, at 10:48, vyom <vyom.tew...@oracle.com> wrote: >> >>> Hi Chris, >>> >>> Please find the updated >>> webrev(h

Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

:57 PM, Chris Hegarty wrote: On 10 May 2016, at 20:52, e...@zusammenkunft.net wrote: Hello, Love it. Yes, this is along the same lines as I was thinking. Not sure about two things, first of all if there are more test cases (especially assertions) needed and Right. Maybe a new test that, 1

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

still only author. I will take a final pass over the updated webrev, do some testing, and then push it for you. -Chris. > Thanks and best regards > Christoph > > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sen

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

On 11 May 2016, at 10:21, Langer, Christoph wrote: > Hi, > > @Chris: As for your points: > >> I agree with the replacement of strcpy with strncpy, but I think we should >> explicitly null terminate in case the src is greater or equal to the dst >> buffer >> size.

Re: RFR 8154234: Examine if netdoc Handler can be removed

On 11 May 2016, at 07:44, vyom wrote: > Hi All, > > Please review the following simple fix for the > issue(https://bugs.openjdk.java.net/browse/JDK-8154234). > >hg rm src/java.base/share/classes/sun/net/www/protocol/netdoc/Handler.java This seems fine to me Vyom.

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

Hi Christoph, On 11 May 2016, at 08:43, Dmitry Samersoff wrote: >> ... >> bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 >> >> webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ I think this is mainly fine, and good to have such cleanup in

Re: RFR: 8155888: java/net/httpclient/QuickResponses.java intermittently failed with java.util.ConcurrentModificationException

On 5 May 2016, at 12:29, Michael McMahon wrote: > Another occasional test case failure. It's a concurrent modification > exception caused > by modifying a list during processing of the list (by the same thread). The > solution > is to keep separate lists of the

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

-Chris. > - Michael > > On 04/05/16 19:12, Chris Hegarty wrote: >> Michael, >> >> getFreePort follows a failed pattern. There is no guarantee that the port >> will >> be “free” when you actually require it. It will only reduce the likelihood of >> failur

Re: RFR JDK-8087113: Websocket API and implementation

On 3 May 2016, at 16:23, Pavel Rappo wrote: > Hello, > > Here's an updated webrev with the latest implementation: > > http://cr.openjdk.java.net/~prappo/8087113/webrev.04/ This looks much better, more straight forward. I will ignore any TODO’s and items mentioned in

Re: RFR: 8155928: Remove hardcoded port numbers from httpclient/Security.java test

Michael, getFreePort follows a failed pattern. There is no guarantee that the port will be “free” when you actually require it. It will only reduce the likelihood of failure. Is there any way that the actual tests needing the port can create it themselves ( i understand that this will be

Re: RFR: 8154238: Drop code to support Windows XP in windows socket impl

On 18/04/16 11:01, Alan Bateman wrote: On 18/04/2016 10:45, Chris Hegarty wrote: The changes look fine. Maybe the bug description should be updated a before pushing, it looks like it affects only legacy networking code and not NIO. Maybe "... and async channels" ? The changes to th

Re: RFR: 8154238: Drop code to support Windows XP in windows socket impl

On 14/04/16 13:49, Claes Redestad wrote: Hi, more code in the Windows socket implementation that can be dropped Bug: https://bugs.openjdk.java.net/browse/JDK-8154238 Webrev: http://cr.openjdk.java.net/~redestad/8154238/webrev.01/ The changes look fine. Maybe the bug description should be

Re: RFR 8154543, NetworkInterfaceStreamTest.java fails intermittently after JDK-8146758

This looks ok to me Felix. -Chris. On 20 Apr 2016, at 08:07, Felix Yang wrote: > Hi there, >I introduced a problem in fix for JDK-8146758. When calling > allNetworkInterfaces(), it will concat sub interfaces into the stream > incorrectly. Then the test fails on a

Re: RFR 8146758, NetworkInterfaceStreamTest.java fails intermittently at comparing network interfaces

On 15/04/16 10:29, Felix Yang wrote: Hi all, please review the following fix. It is an intermittent failure because of Teredo Tunneling Pseudo-Interface. Bug: https://bugs.openjdk.java.net/browse/JDK-8146758 Webrev: http://cr.openjdk.java.net/~xiaofeya/8146758/webrev.00/ Looks ok to me.

Re: RFR JDK-8154487: java.httpclient/sun.net.httpclient.hpack.DecoderTest failing on Windows

On 19 Apr 2016, at 10:15, Pavel Rappo wrote: > Hi, > > Could you please review my change for JDK-8154487? > > http://cr.openjdk.java.net/~prappo/8154487/webrev.00/ Looks ok Pavel. -Chris. > This shows up only on Windows machines where EOL is '\r\n' rather than '\n'.

Re: RFR: 8154454: Fix compilation issue in PlainSocketImpl

Looks ok Claes. -Chris. On 18/04/16 15:38, Claes Redestad wrote: Hi, a small omission in JDK-8154238 cause Windows builds to fail. Sorry about that, see patch to fix this below (I was 100% certain I had run this through JPRT last week) Bug: https://bugs.openjdk.java.net/browse/JDK-8154454

Re: RFR: 8154185: Drop code to support Windows XP in DefaultDatagramSocketImplFactory

On 13 Apr 2016, at 22:31, Claes Redestad wrote: > > Hi, > > since we're dropping support for Windows XP in JDK 9, we can simplify > initialization of DefaultDatagramSocketImplFactory. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154185 > Webrev:

RFR [9] 8153372: Remove sun.misc.ManagedLocalsThread from jdk.httpserver

8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be updated to use it. This change updates the code in the

Re: [JDK-8016521] IPV6 address selection

On 12/04/16 21:27, Bernd Eckenfels wrote: Hello, a while back I brought up the discussion that there is no preferIPV6=system (or similar) setting which allows to turn off the reordering of address families by Java. Because only the OS can try to correctly do target address determinaton. A Bug

Re: RFR: 8071125: Improve exception messages in URLPermission

On 20 Apr 2016, at 18:19, Seán Coffey wrote: > webrev updated in place with suggestion from Pavel (off thread) to place > quotes around the problem values. Quotes or square brackets. My preference is for the latter, but go with whichever you like. Consider this

RFR [9] 8155578: OpenJDK build failed after JDK-8044773

This is a review for a trivial, but build-fatal, addition of a qualified export to the jdk.net module, that was mistakenly omitted from the changes for 8044773. $ hg diff -U 11 diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java ---

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

As a follow up to JDK-8156521, and when comparing against the version of this file in jdk8u-dev a few minor issues were noticed. There is a free of a memory structure that was missed somehow in the 9 version of this file ( it is already in the 8 version ). The remaining few changes are just some

Re: RFR 8157811 [9] Additional minor fixes and cleanups in Networking native code

} > > *flags = if2.lifr_flags; > > Best regards > Christoph > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Chris >> Hegarty >> Sent: Mittwoch, 25. Mai 2016 11:50 >> To: OpenJDK Network Dev list &

Re: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9

On 25 May 2016, at 14:04, Svetlana Nikandrova wrote: > > Hi Chris, > > thank you for your comments. Please see updated review. (I left braces in one > line "if" blocks, hope it wasn't strong objection) > >

Re: RFR JDK-8161091 Incorrect Stream.FlowControl implementation allows to send DataFrame even when window size was exhausted

> On 11 Jul 2016, at 23:47, Sergey Kuksenko wrote: > > I am awfully sorry, previous fix was incorrect. > Please, review the right version: > http://cr.openjdk.java.net/~skuksenko/jep110/8161091/webrev.01/ Looks good. Thanks Sergey. -Chris. > On 07/08/2016 02:40

Re: RFR 8163586: java.net.http.RawChannel has been made public by mistake

Reviewed. -Chris. > On 10 Aug 2016, at 15:37, Pavel Rappo wrote: > > Hello, > > Could you please review the following change for [1]? > > http://cr.openjdk.java.net/~prappo/8163586/webrev.00/ > > The subject field says it all. I've also re-checked the previous

Re: Help needed: Java Socket and close detection

Some further reading… https://docs.oracle.com/javase/8/docs/technotes/guides/net/articles/connection_release.html -Chris. > On 13 Jul 2016, at 21:37, Dmitry Samersoff > wrote: > > Christoph, > > My $0.2 > > Typically you see RST packet when the data come to a

Re: RFR [9] 8078568 java/net/URLPermission/URLTest.java fails intermittently with BindException

ww.protocol.http.HttpURLConnection.getInputStream0(java.base/HttpURLConnection.java:1505) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(java.base/HttpURLConnection.java:1433) at java.net.HttpURLConnection.getResponseCode(java.base/HttpURLConnection.java:480) ... 10 more cheers, -- danie

Re: PING: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

in advance Christoph -Original Message- From: Langer, Christoph Sent: Mittwoch, 13. Juli 2016 17:02 To: 'Chris Hegarty' <chris.hega...@oracle.com> Cc: net-dev@openjdk.java.net Subject: RE: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listi

Re: RFR (S) JDK-8160174: java.net.NetworkInterface - fixes and improvements for network interface listing

Christoph, > On 11 Jul 2016, at 14:36, Langer, Christoph wrote: > > Hi Chris (or anyone who is holding a stake in the NetworkInterface native > implementation), > > I’ve spent some time on cleaning up NetworkInterface.c and came up with a > bigger

Re: RFR 8144692: HttpServer API: use of non-existant method in example in package Javadoc

On 12/07/16 13:53, Vyom Tewari wrote: Hi Pavel, Thanks for review, i updated the webrev(http://cr.openjdk.java.net/~vtewari/8144692/webrev0.0/index.html ) in place. Looks fine. -Chris. Thanks, Vyom On Tuesday 12 July

Re: RFR 8022580: sun.net.ftp.impl.FtpClient.nameList(String path) handle "null" incorrectly

.04/> Hi Svetlana, The test looks good to me know :-) best regards, -- daniel Thank you, Svetlana On 12.07.2016 17:25, Chris Hegarty wrote: Svetlana, <http://cr.openjdk.java.net/%7Esnikandrova/8022580/webrev.03/> The source code changes look fine. On the test... On 11 Jul 20

RFR [9] 8160993: Fix headers in the java/net/http package

This is a change fix the license headers in the java/net/http package. There was a cut'n'paste error that mostly missed the last line of the header. Also, I added a new line after the header consistently in every file. As well as a few places that had other minor issues.

Re: RFR: 8160786: No CCC for public class java.net.http.AsyncSSlDelegate

On 11/07/16 13:42, Michael McMahon wrote: Simple change. An implementation class was made public by mistake http://cr.openjdk.java.net/~michaelm/8160786/webrev.1/ Reviewed. -Chris.

Re: RFR 8163149/9, Typo in java.net.http.AuthenticationFilter

> On 5 Aug 2016, at 09:05, Felix Yang wrote: > > Hi there, > > please review a simple patch for java.net.http.AuthenticationFilter. There > is a typo in the code. "Proxy-Authentication" should be replaced with > "Proxy-Authenticate" > > Bug:

Re: JDK 9 RFR of 8162745: content-types.properties files are missing some modern types

> On 3 Aug 2016, at 14:32, Brian Burkhalter wrote: > > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8162745 > Patch:http://cr.openjdk.java.net/~bpb/8162745/webrev.00/ >

Re: RFR 8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently

On 8 Aug 2016, at 13:55, Svetlana Nikandrova wrote: >> ... >> On 02.08.2016 20:25, Svetlana Nikandrova wrote: >>> Pavel, Chris, >>> >>> thank you for you replays. I believe I addressed all Pavel's comments >>> except the one mentioned by Chris below. I saw tests

Re: RFR 8162876: [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails intermittently

> On 1 Aug 2016, at 12:03, Pavel Rappo wrote: > ...return len; > > 5. I believe we should add 8162876 to @bug Strictly speaking, we should not. The @bug should capture the bug numbers that the test exercises the changes for. It is not necessary to include the bug

Re: RFR 8161291: Serialization Tests for URLPermission is failing

On 22/07/16 09:59, Daniel Fuchs wrote: Hi Vyom, It would be helpful in the future to include a link to the JBS issue in your request for review. 464 //The colon separator need to be present even if the request headers list is empty I would suggest the comment to be a little more

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

gt; > > Best regards, > Arno > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Montag, 30. Januar 2017 17:14 >> To: Zeller, Arno <arno.zel...@sap.com> >> Cc: net-dev@openjdk.java.net >> Subject: R

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

> On 31 Jan 2017, at 19:14, Zeller, Arno wrote: > > Hi Chris, > > thanks for all the improvements. I imported your webrev and prepared another > webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8170868.6/ Much better, thanks Arno. Two more minor suggestions ( patch

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

Arno, I found an issue on Windows when proxies are specified per-protocol, i.e. they are returned with their optional scheme set. I believe that the scheme should be checked, at least without this change FTP proxies were being returned for HTTP URL's, on my machine. $ hg -R jdk diff diff -r

Re: RFR [9] Warning notice for types in Incubator Modules

ecipes are created. Setting it on the phony docs-javadoc > target will not help incremental builds. Updated in place http://cr.openjdk.java.net/~chegar/incubator_taglet/ -Chris. > /Erik > > > On 2017-01-24 15:08, Chris Hegarty wrote: >> As per the guidance in JEP 11 [1

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

proxies. -Chris. > Best regards, > Arno > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of >> Zeller, Arno >> Sent: Mittwoch, 11. Januar 2017 15:21 >> To: Chris Hegarty <chris.hega...@oracle.com> >&

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

Arno, On 11/01/17 14:21, Zeller, Arno wrote: Hi Chris, I have addressed your comments in a new webrev. Can you please have a look at this one? http://cr.openjdk.java.net/~clanger/webrevs/8170868.3/ This is looking much better, thank you. Some smaller comments and observations ( I'm still

RFR [9] 8175261: Per-protocol setting for not working for JAR URLConnection defaultUseCaches

The fix for 8163449 [1] "Allow per protocol setting for URLConnection defaultUseCaches", does not work for JAR URLs ( which embed URLs to the actual artifact ). The problem is that sun.net.www.protocol.jar.JarURLConnection passes all of the [g|s]et[Default]UseCaches() method calls to the

RFR [9] Warning notice for types in Incubator Modules

As per the guidance in JEP 11 [1], the javadoc for types in incubator modules should have a clear and explicit warning notice. To that end, I’ve added a simple inline taglet that can be used to effectively inject a standard notice, and applied it to all public types in the HTTP module ( I’ll

Re: RFR: 8167178 Exported elements referring to inaccessible types in java.naming

Looks good. Thanks Vyom. -Chris. > On 16 Jan 2017, at 09:10, Vyom Tewari wrote: > > Hi All, > > Please review below the small fix for the issue. > > BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 > > The compatibility impact is minimum as no code in JDK is

Re: Review request JDK-8165180: Provide a shared secret to access non-public ServerSocket constructor

> On 31 Aug 2016, at 21:48, Mandy Chung wrote: > > This patch introduces JavaNetSocketAccess to allow access to non-public > ServerSocket constructor that is accessed by some other area as a clean up. > > Webrev: >

Re: [8u-dev] RFR (XXS) and request for approval: 8165320: Small flaw when integrating 8160174 to JDK8

On 02/09/16 15:02, Langer, Christoph wrote: Hi, can you please review and approve a tiny and straightforward fix for AIX only in JDK8. Bug: https://bugs.openjdk.java.net/browse/JDK-8165320 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8165320.8udev/ This looks fine. Reviewed.

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Vyom, >>> webrev(http://cr.openjdk.java.net/~vtewari/8075484/webrev0.1/index.html There is some concern about the potential performance effect, etc, of gettimeofday, maybe there is a way out of this. The reuse of NET_Timeout is good, but it also calls gettimeofday. It seems that a specific

Re: HTTP client API

Martin, Wenbo, We are considering the feedback, will take it under advisement, and reply in due course. -Chris. > On 26 Aug 2016, at 22:14, Martin Buchholz wrote: > > I don't know much about http, but I believe those who say that it's very hard > to get the API right.

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

Just no more than is already there. and adjust the originally specified timeout accordingly, and for the edge case after the non blocking read. After an initial skim, your suggestion seems reasonable. -Chris. regards Mark On 05/09/2016 12:02, Chris Hegarty wrote: Vyom, >>> webrev(http://cr.openj

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

rns before the timeout? Just an idea. -Chris. > Thanks, > > Vyom > > > On Monday 05 September 2016 08:37 PM, Chris Hegarty wrote: >> On 05/09/16 15:37, Mark Sheppard wrote: >>> >>> if the desire is to avoid making double calls on gettimeofday in the >&

Re: java.net.http orElse(null) in SSLDelegate and other nits

Thanks for reporting these issues Bernd, > On 27 Aug 2016, at 17:25, Bernd Eckenfels wrote: > > Hello, > > trying to understand the new jdk9 hierachy I noticed that this code: > >

Re: Ping: RFR(S): 8163181: Further improvements for Unix NetworkInterface native implementation

Apologies Christoph, this dropped off my list and I forgot to get back to it. > On 2 Sep 2016, at 08:22, Langer, Christoph wrote: > > Hi (Mark or Chris?), > > as this RFR is outstanding for quite a while and it merely is a minor change > which only cleans up coding,

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

ards the end of Java_java_net_SocketInputStream_socketRead0, for example EBADF is handled in two places. -Chris. I need help from some one to build and test latest changes on AIX, may be Christoph can help. Thanks, Vyom On Tuesday 06 September 2016 06:25 PM, Chris Hegarty wrote: Vyom, On 6 Sep 2016, at 10:20, Vyom Tewa

Re: RFR (XS): JDK-8165711:java/net/SetFactoryPermission/SetFactoryPermission.java needs to run in ovm mode

Reviewed. -Chris. > On 8 Sep 2016, at 16:08, Sean Coffey wrote: > > Looking for review for this simple edit. Testcase should run in ovm mode. > > https://bugs.openjdk.java.net/browse/JDK-8165711 > > patch : > > diff --git

Re: RFR: 8161016: Strange behavior of URLConnection with proxy

On 12/08/16 20:56, Ramanand Patil wrote: Hi Aleksey, Thank you for your review. In the exception handler block: when last proxy fails, it was using a DIRECT connection, but in the fixed version it was just a re-try once with the last proxy before failing the connection. Considering your

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

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

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

java.se.oracle.com/source/s?defs=SO_REUSEPORT=jdk9-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

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

, 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

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

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

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

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

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

> On 7 Sep 2016, at 14:17, Rob McKenna wrote: > > Hi folks, > > Looking for a review of this simple enough fix: > > http://cr.openjdk.java.net/~robm/6947916/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-6947916 I think that the source changes are good, but the

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

t; >>>>> Apologies, I'm guilty of "just doing what adjacent tests do" here. >>>>> >>>>> That shell script is actually there in the test source already, but >>>>> generating the jar from the test means theres no need to use it

Re: RFR 8075484:SocketInputStream.socketRead0 can hang even with soTimeout set

t;>>> >>>> Thanks, >>>> Vyom >>>> >>>> On 9/8/2016 12:32 PM, Langer, Christoph wrote: >>>> >>>>> Hi Vyom, >>>>> >>>>> ok, thanks. I have one addition to my proposal: I don't think there's a >>

Re: RFR - 8165988: Test JarURLConnectionUseCaches.java fails at windows: failed to clean up files after test

On 14 Sep 2016, at 21:37, Rob McKenna wrote: > > Hi folks, > > A resource cleanup issue can cause this test to fail on windows, fix is to > run in othervm: > > http://cr.openjdk.java.net/~robm/8165988/webrev.01/ Looks fine Rob. -Chris.

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

Re: RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet

Christoph, On 22/09/16 21:59, Langer, Christoph wrote: Hi, while looking at utility functions for creating exceptions in libjava/libnet I found a small spot that should be consolidated right away. The function NET_ThrowSocketException does only exist in the windows native implementation and

Re: RFR 8163482: java.net.URLPermission.getActions() adds a trailing colon when header-names is empty

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

Re: Introduce IOException subclass for ECONNRESET

t-dev-boun...@openjdk.java.net] On Behalf Of Chris Hegarty Sent: Montag, 12. September 2016 17:07 To: Florian Weimer <fwei...@redhat.com>; Norman Maurer <norman.mau...@googlemail.com>; net-dev@openjdk.java.net Subject: Re: Introduce IOException subclass for ECONNRESET On 12/09/16 14:50, Floria

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

Re: RFR 8166359/9, java/net/URLPermission/nstest/lookup.sh fails if proxy is set, since fix for JDK-8161016

Felix, On 21/09/16 03:31, Felix Yang wrote: Hi Chris, On 2016/9/20 23:22, Chris Hegarty wrote: Felix, On 20 Sep 2016, at 13:57, Felix Yang <felix.y...@oracle.com> wrote: Hi all, please review the following test fix. It explicitly disables proxy to make sure the test not af

Re: [9] RFR: 8164591: sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java failed with SSLHandshakeException

On 15 Sep 2016, at 02:55, Xuelei Fan wrote: > > On 9/15/2016 9:45 AM, Artem Smotrakov wrote: >> Well, in this particular case it's not clear that it has the same issue >> with free port (at least to me). The exception occurred on client side, >> so it's not the case where

Re: RFR(s): 8166285: Missing dependencies java.httpclient for tests from java/net pachage

> On 19 Sep 2016, at 15:33, Sergei Kovalev wrote: > > Hello team, > > Could you please review below fix for: > > BugID: https://bugs.openjdk.java.net/browse/JDK-8166285 > Webrev: http://cr.openjdk.java.net/~skovalev/8166285/webrev.00/ Reviewed. Thanks Sergei.

Re: RFR 8085049/9, java/net/MulticastSocket/TimeToLive.java fails intermittently with "Address already in use"

Looks good. Thanks Felix. -Chris. On 23/09/16 10:21, Felix Yang wrote: Hi there, please review a minor test fix to avoid hard-coded port usage, which leads to "Address already in use" issue intermittently. Bug: https://bugs.openjdk.java.net/browse/JDK-8085049 Since it is just a 1

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

/webrev.03/ Thanks Rob. This latest version looks good to me. -Chris. -Rob On 22/09/16 06:12, Chris Hegarty wrote: On 22 Sep 2016, at 18:04, Mark Sheppard <mark.shepp...@oracle.com> wrote: it is good that you added the additional error code, "cover all bases", as they

Re: HTTP client API

On 22/09/16 08:54, Chris Hegarty wrote: On 22 Sep 2016, at 00:14, Michael McMahon <michael.x.mcma...@oracle.com> wrote: Martin The source is available in the JDK 9 sandbox (http-client-branch) at http://hg.openjdk.java.net/jdk9/sandbox/ I think it has been updated to reflect t

Re: HTTP client API

On 22 Sep 2016, at 00:14, Michael McMahon wrote: > > Martin > > The source is available in the JDK 9 sandbox (http-client-branch) at > http://hg.openjdk.java.net/jdk9/sandbox/ > > I think it has been updated to reflect the API as described below. Apologies, it

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

> On 22 Sep 2016, at 18:04, Mark Sheppard wrote: > > > it is good that you added the additional error code, "cover all bases", as > they say. > In any case your exception handling will inform if something has been > missed, should it occur. > So at the risk of

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

On 18 Aug 2016, at 10:26, Felix Yang wrote: > > Hi all, > >please review a new test, which tries to verify "Proxy-Authenticate" > header can be handled correctly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163561 > > Webrev:

Re: RFR 8163561, add a test for Proxy Authentication in HTTP/2 Client API

; Looks good. Thanks Felix. -Chris. > > Thanks, > Felix > On 2016/8/18 23:43, Chris Hegarty wrote: >> On 18 Aug 2016, at 10:26, Felix Yang <felix.y...@oracle.com> wrote: >>> Hi all, >>> >>>please review a new test, which tries t

Re: RFR 8005068: HttpCookie does not correctly handle negative maxAge values

On 24/08/16 13:18, Svetlana Nikandrova wrote: ... Hello, please review this fix. Javadoc for HttpCookie setMaxAge states that " A negative value means that cookie is not stored persistently" and "max age is unspecified", but hasExpired only checks for "-1" as possible negative value. Also

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

le.com] > Sent: Wednesday, September 28, 2016 1:26 AM > To: Chris Hegarty <chris.hega...@oracle.com>; Mark Sheppard > <mark.shepp...@oracle.com>; net-dev <net-dev@openjdk.java.net>; Kaczmarek, > Eric <eric.kaczma...@intel.com>; Viswanathan, Sandhya > &l

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

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

Re: RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet

toph. Thanks, -Chris. > I've replaced the JNU_JAVANETPKG and JNU_JAVAIOPKG macros with the full > exception class names. > > Best regards > Christoph > >> -Original Message- >> From: Chris Hegarty [mailto:chris.hega...@oracle.com] >> Sent: Dienstag

Re: RFR 8153674: Expected SocketException not thrown when calling bind() with setReuseAddress(false)

[1] https://bugs.openjdk.java.net/browse/JDK-6432031 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 setRe

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

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

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

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:

Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

ot actually need othervm, but of course it should be fine with it too. -Chris. > Thanks, > Felix > On 2016/9/27 15:55, Chris Hegarty wrote: >>> On 27 Sep 2016, at 03:08, Felix Yang <felix.y...@oracle.com> wrote: >>> >>> Hi all, >>> >>>pleas

Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

On 27 Sep 2016, at 09:35, Felix Yang <felix.y...@oracle.com> wrote: > > Chris, > >I will push without othervm Thanks. If we see future issues with this test, then we can add it back. -Chris. > -Felix > On 2016/9/27 16:29, Chris Hegarty wrote: >> On 27

Re: RFR - 8166747: Add invalid network / computer name cases to isReachable known failure switch

On 27 Sep 2016, at 01:02, Mark Sheppard wrote: > > Hi Rob, >changes look reasonable … +1 > perhaps align the two additions below the existing ERROR_XXX set, all neat > and tidy :-) +1 -Chris. > regards > Mark > > On 27/09/2016 00:09, Rob McKenna wrote: >> Hi

Re: RFR 8154525, java/net/ServerSocket/ThreadStop.java fails intermittently with error while cleaning up threads after test

> On 27 Sep 2016, at 03:08, Felix Yang wrote: > > Hi all, > >please review following test fix. > > Bug: > >https://bugs.openjdk.java.net/browse/JDK-8154525 > > Webrev: > >http://cr.openjdk.java.net/~xiaofeya/8154525/webrev.00/ > > This test has been

Re: RFR(XS): 8166584: Remove obsolete utility function NET_ThrowSocketException in windows libnet

that I touch here > and if yes, shall I use the literal name or the JNU_JAVANETPKG define? Any > opinion on that? My preference is to remove JNU_JAVANETPKG, and just use "java/net/“. -Chris > Thanks for taking care of this, > Christoph > > >> -Original

<    5   6   7   8   9   10   11   12   13   14   >