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

On 13 Nov 2015, at 04:59, Sebastian Sickelmann <sebastian.sickelm...@gmx.de> wrote: > Hi, > > my recordings related to this thread show me that this thread is open. Sorry > for loosing track for some time. > > If i am right i got an thumbs up review result from Chris

Re: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use

8140472 ( it is a bug in the test itself ). -Chris. Thanks, Felix On 2016/1/6 13:49, Chris Hegarty wrote: Hi Felix, On 6 Jan 2016, at 05:09, Felix Yang <felix.y...@oracle.com> wrote: Hi all, please review the fix for java/net/ipv6tests/TcpTest.java, which replaces hard-coded ports with d

Re: RFR 8140472/9, java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use

Hi Felix, On 6 Jan 2016, at 05:09, Felix Yang wrote: > Hi all, >please review the fix for java/net/ipv6tests/TcpTest.java, which replaces > hard-coded ports with dynamic free ports on runtime. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140472 > Webrev:

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

Hi Volker, On 5 Jan 2016, at 17:49, Volker Simonis wrote: > Hi, > > can somebody please review this small test fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8146482/ > https://bugs.openjdk.java.net/browse/JDK-8146482 This change looks good to me.

Re: RFC on 8146041: java.net.URLConnection.guessContentTypeFromStream() does not recognize TIFF streams

On 6 Jan 2016, at 02:22, Brian Burkhalter wrote: > This core-libs-dev RFR > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037847.html > > was already approved on core-libs-dev but I would like to make sure there is > no objection from the

Re: RFR: 8146526: Improve java.net.URI$Parser startup characteristics

On 5 Jan 2016, at 22:47, Claes Redestad wrote: > Hi, > > please review this patch to cleanup URI$Parser to help URI construction when > run with the interpreter, mostly by inlining wrapping methods: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 > >

Re: RFR 8146209/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java still fails after fix JDK-8131155

This looks fine Felix, thanks. -Chris > On 25 Dec 2015, at 06:29, Felix Yang wrote: > > Hi all, >please review the fix for > java/net/NetworkInterface/NetworkInterfaceStreamTest.java. There are some > situations missed in prior fix for JDK-8131155, which should

Re: RFR 8133704/9, java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java may fail with address already in use

Hi Felix, On 08/01/16 08:36, Felix Yang wrote: Hi all, please review the fix for java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.java Bug: https://bugs.openjdk.java.net/browse/JDK-8133704 Webrev: http://cr.openjdk.java.net/~xiaofeya/8133704/webrev.00 This looks good.

Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java

> On 7 Jun 2016, at 05:50, Hamlin Li wrote: > > Would you please review the following simple doc patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8158881 > webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.00/ I’m not sure why the URL’s were ever changed

Re: RFR of JDK-8158881: Doc typo in src/../java/net/URI.java

e changed URLs in doc are not valid URLs, they just sample. > Please check webrev: http://cr.openjdk.java.net/~mli/8158881/webrev.01/ Thank you Hamlin ( and Brad ), this looks good. -Chris. > Thank you > -Hamlin >> >> Thanks, >> >> Brad >> >> [1

Re: JDK 9 RFR of JDK-8159012: Problem list sun/net/www/http/ChunkedOutputStream/checkError.java

Looks fine Amy. -Chris. > On 8 Jun 2016, at 01:48, Amy Lu wrote: > > sun/net/www/http/ChunkedOutputStream/checkError.java > This test failed intermittently (JDK-8041924), and recently observed failing > with high frequency. > > Please review this patch to put the test to

RFR [9] 8041924: [TESTBUG] sun/net/www/http/ChunkedOutputStream/checkError.java fails on some systems

This test has been seen to fail intermittently. There is an assumption in the test that the client-side will fill the outgoing TCP buffer by writing 1 megabyte of data, allowing for the server-side to close the connection out from under it. This is the crux of the test. By slowing down the

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

Looks fine. -Chris. On 09/06/16 11:54, Pavel Rappo wrote: Hi, Could you please review the following change for JDK-8157273? http://cr.openjdk.java.net/~prappo/8157273/webrev.01/ This change addresses some WebSocket API refinements and enhancements from [1]. Currently WebSocket API allows

Re: 8158519: Incorrect network mask and broadcast address on Linux when there are multiple IPv4 addresses on an interface

s change got pushed. > > Thanks and Best regards > Christoph > > >> -Original Message- >> From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Dmitry >> Samersoff >> Sent: Donnerstag, 2. Juni 2016 19:35 >> To: Chris Hegarty <chris.

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

Following this discussion, I think the point is that the size of the send queue is an implementation detail, and therefore cannot be replied upon ( another implementation could have a smaller upper bound ). Having a method on builder similar to the sketch below, may address this concern. /**

RFR [9] 8157045: NPE during websocket communication with wss

8157045 [1] is blocking folks doing test development for WebSockets. I would like to push this “temporary” change, to unblock them, until we can refactor some of this area to fix what appears to be a more significant issue ( readImpl(ByteBuffer) can read bytes into a different ByteBuffer, but

Re: RFR JDK-8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales

On 13/06/16 16:39, Naoto Sato wrote: Hi Pavel, Locale.setDefault() sets the JVM wide default locale, so I'd suggest add try/finally block to resume the locale to the previous one. I did suggest something like this to Pavel off-list, but then noticed that the test runs in othervm mode, so

Re: RFR JDK-8159039: sun/net/httpclient/hpack/HeaderTableTest.java fails on some locales

Thanks Pavel. Reviewed. -Chris. On 13/06/16 11:29, Pavel Rappo wrote: Hi, Could you please review the following change for JDK-8159039? http://cr.openjdk.java.net/~prappo/8159039/webrev.00/ This change contains a fix for 8159039 as well as a number of tiny editorial changes. Thanks, -Pavel

Re: RFR 8157816, Mark 4 httpclient tests as intermittently failing

This is sad, but I agree. Reviewed. -Chris. On 30/05/16 08:18, Felix Yang wrote: Hi all, please review the change to mark following tests with keyword 'intermittent'. These tests have been observed to fail intermittently for a while. test/java/net/httpclient/SplitResponse.java

Re: Reminder about reported problem in NetworkInterface.c

Doychin, Apologies, I am having issues accessing that URL, can you please post the output of 'hg diff' to this list, and I will examine your proposed patch. -Chris. On 29/05/16 21:30, Doychin Bondzhev wrote: Hi guys, here is an updated webrev against current NetworkInterface.c

Re: Reminder about reported problem in NetworkInterface.c

in Bondzhev > > On Thu, May 26, 2016 at 4:07 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: > > > On 26 May 2016, at 13:57, Chris Hegarty <chris.hega...@oracle.com> wrote: > > > > > >> On 26 May 2016, at 13:46, Doychin Bondzhev <

8158519: Incorrect network mask and broadcast address on Linux when there are multiple IPv4 addresses on an interface

Doychin, et al, I finally got time to look at the issue you reported and your suggested patch. I filed 8158519 [1] to track the issue. I think your suggested patch may be ok, but I just wanted to push on the ioctl approach. I found an alternative, and verified that it works as expected.

Re: RFR [9] 8158525: Update a few java/net tests to use the loopback address instead of the host address

). It works fine all systems I’ve tested with. Update in-palce: http://cr.openjdk.java.net/~chegar/8158525/ -Chris. > Roger > > > > On 6/2/2016 9:22 AM, Chris Hegarty wrote: >> The following networking tests have been seen to fail from a timeout, when >> the host

Re: Reminder about reported problem in NetworkInterface.c

> On 26 May 2016, at 13:46, Doychin Bondzhev wrote: > > Hi, I have my signed Oca processed. I hope now we can continue with proposed > patch? I cannot find you on http://www.oracle.com/technetwork/community/oca-486395.html#list Please confirm your that you are on this

Re: Reminder about reported problem in NetworkInterface.c

> On 26 May 2016, at 13:57, Chris Hegarty <chris.hega...@oracle.com> wrote: > > >> On 26 May 2016, at 13:46, Doychin Bondzhev <doyc...@dsoft-bg.com> wrote: >> >> Hi, I have my signed Oca processed. I hope now we can continue with >> prop

Re: Ping - RFR 8158023: SocketExceptions contain too little information sometimes

Christoph, > On 1 Jun 2016, at 08:33, e...@zusammenkunft.net wrote: > > Hello, > > Since nobody commented, here is my non binding comment: > > I am not sure which Exception call-site actually improved (i.e. added the > error code)? I would split out the improvement of this/those throws and

Re: RFR JDK-8157273: Simplify outgoing messages queueing policy in WebSocket API

> On 14 Jun 2016, at 17:24, Simone Bordet wrote: > >> ... > > However, you still want to use the CFs for exception reporting. Of course. We should not introduce a model that is at odds with how exceptions are handled in this API. How about: 1) Leave the sendXXX

Re: RFR JDK-8156742: Miscellaneous WebSocket API improvements

> On 21 Jun 2016, at 12:21, Pavel Rappo wrote: > > Hi, > > Let me try again to propose the following set of changes: > > http://cr.openjdk.java.net/~prappo/8156742/webrev.02/ This mainly looks fine, just a small comment: - WebSocket.java "Or to close abruptly

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good. Just some ideas to simplify the wording. * After a Close message has been received, the implementation will * close the connection automatically. However, the client may finish * sending the current sequence of partially sent message parts, if any. * To

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

The code changes look fine, but the bigger question is whether we want to support actions without any ‘method’ being specified, like “:X-Bar”? Should the constructor throw IAE, or is that even possible now, it would require a spec clarification ( would that invalidate existing code already doing

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

> On 16 Jun 2016, at 18:55, Roger Riggs wrote: > > Hi Vyom, > > Looks ok, +1. I attempted to add a test for https, and just realised that the javax.net.SocketFactory does not support Socket(Proxy). It may be worth capturing this issue somewhere, but it is way

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

On 21 Jun 2016, at 11:21, Chris Hegarty <chris.hega...@oracle.com> wrote: > > The code changes look fine, but the bigger question is whether we > want to support actions without any ‘method’ being specified, like > “:X-Bar”? Should the constructor throw IAE, or is that e

Re: RFR 8144008: Setting NO_PROXY on an URLConnection is not complied with

(); +return new java.net.Socket(Proxy.NO_PROXY)); } protected InetAddress getLocalAddress() throws IOException { if (serverSocket == null) throw new IOException("not connected”); -Chris. > On 16 Jun 2016, at 21:09, Chris Hegarty <chris.hega...

Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

, if necessary. And/Or make implementation changes if issues arise from this. -Chris. > On 21 Jun 2016, at 06:56, Chris Hegarty <chris.hega...@oracle.com> wrote: > > On 20 Jun 2016, at 21:36, Sergey Kuksenko <sergey.kukse...@oracle.com> wrote: >> >> Hi, >> &

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

> On 23 Jun 2016, at 14:48, Simone Bordet wrote: > > ... > > WebSocket's close mechanism is a double half close, like TCP. > In TCP the semantic is very clear: sideA can half close, sideB can > continue sending data, sideA will continue reading data, until sideB > half

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

> On 23 Jun 2016, at 15:36, Simone Bordet <simone.bor...@gmail.com> wrote: > > Hi, > > On Thu, Jun 23, 2016 at 3:58 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: >> At one point I thought the same, but after, yet another, re-reading of the

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good Pavel, just a few minor comments. > On 17 Jun 2016, at 19:37, Pavel Rappo wrote: > > …. > * The WebSocket implementation responds to the received Ping > * message using a strategy of its choice, but withing the boundaries of

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

I think this is good Pavel, just a few minor comments. > On 17 Jun 2016, at 19:37, Pavel Rappo wrote: > > …. > * The WebSocket implementation responds to the received Ping > * message using a strategy of its choice, but withing the boundaries of

Re: RFR JDK-8158980: Memory leak in HTTP2Connection.streams

> On 20 Jun 2016, at 21:24, Sergey Kuksenko wrote: > > Hi, > > Could you please review the following fix for JDK-8158980? > http://cr.openjdk.java.net/~skuksenko/jep110/8158980/webrev.00/ This looks good to me Sergey. I can sponsor it for you. -Chris.

RFR [9] 8157166: Update spec to account for platforms that do not support multicast

Some platforms do not support multicasting, but the current spec requires that it is supported. It seems reasonable to relax this, somewhat, so that multicasting is effectively optional on these platforms. java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join method

Re: RFR [9] 8157166: Update spec to account for platforms that do not support multicast

> On 16 Jun 2016, at 16:31, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 16/06/2016 16:03, Chris Hegarty wrote: > >> Some platforms do not support multicasting, but the current spec requires >> that >> it is supported. It seems re

Re: Preliminary RFR JDK-8159053: Improve onPing/onClose behavior

On 23/06/16 18:09, Simone Bordet wrote: Hi, On Thu, Jun 23, 2016 at 7:00 PM, Pavel Rappo wrote: But I still think we probably more safe assuming the intersection of our understandings, rather than a union :-) Chris and I agreed, so now you're minority :) Well, I

Re: RFR 8071660 :URLPermission not handling empty method lists correctly

On 17/06/16 15:09, Vyom Tewari wrote: Hi, Please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8071660/webrev0.3/index.html ). I fixed the typo along with spaces issue. Thanks Vyom. Looks good. -Chris.

Re: RFR: 8159745: Remove java.net.Parts

On 17/06/16 15:05, Claes Redestad wrote: On 2016-06-17 16:04, Alan Bateman wrote: On 17/06/2016 14:43, Claes Redestad wrote: Hi, URL.java defines a package-private class Parts, which can be trivially inlined in the one place where it's currently used. Webrev:

Re: RFR JDK-8158690 "GET request via HTTP/2 has a huge delays due to Nagle’s Algorithm and Delayed ACK clash"

Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1f3481f377e6 -Chris. > On 23 Jun 2016, at 10:41, Chris Hegarty <chris.hega...@oracle.com> wrote: > > Sergey and I discuss this off-line and the potential performance improvement > here is very significant; raises performan

Re: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily

On 8 Jan 2016, at 14:41, Claes Redestad wrote: > Hi, > > please review this patch to lazily create schemeSpecificPart for non-opaque > URIs. This change accounts for some improvement in footprint characteristics > and a 10-20% improvement on URI creation

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 18/01/16 14:09, Alan Bateman wrote: On 17/01/2016 15:30, Claes Redestad wrote: Hi, please review this patch which might make URI.toURL more efficient Webrev: http://cr.openjdk.java.net/~redestad/8147462 Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 This patch exploits the fact

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

> On 18 Jan 2016, at 16:20, Claes Redestad <claes.redes...@oracle.com> wrote: > > On 2016-01-18 15:34, Chris Hegarty wrote: >> On 18/01/16 14:09, Alan Bateman wrote: >>> >>> On 17/01/2016 15:30, Claes Redestad wrote: >>>> Hi, >>>>

Re: RFR: 8087112 HTTP API and HTTP/1.1 implementation

On 04/02/16 16:14, Michael McMahon wrote: Hi, The following webrevs are for the initial implementation of JEP 110. Most of it is in the jdk repository with some build configuration in the top level repo for putting this code in its own module (java.httpclient).

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 27 Jan 2016, at 17:24, Claes Redestad wrote: > > On 2016-01-18 17:20, Claes Redestad wrote: >> >> The ability for URLStreamHandler implementations to override the parseURL >> method seem to prevent this improvement unless we only do this for a subset >> of

Re: RFR: 8148626: URI.toURL needs to use protocol Handler to parse file URIs

> On 31 Jan 2016, at 00:58, Claes Redestad wrote: > > Hi, > > On 2016-01-30 19:35, joe darcy wrote: >> Hello, >> >> The change looks okay in that the new code is limited to the jrt protocol. I >> assume the failing test >> >>java/net/URL/B5086147.java >> >>

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 28 Jan 2016, at 16:38, Claes Redestad <claes.redes...@oracle.com> wrote: > On 2016-01-28 16:52, Chris Hegarty wrote: >>> ... >> This looks fine Claes. > > Thanks, Chris! > >> >> Maybe just a comment on the fact that character based

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

Felix, On 14 Jan 2016, at 06:07, Felix Yang wrote: > Hi all, >please review the fix for > test/java/net/SocketPermission/SocketPermissionTest.java, which fails > frequently with "java.net.BindException: Address already in use". > > Bug:

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

On 20 Jan 2016, at 06:36, Chris Hegarty <chris.hega...@oracle.com> wrote: > Felix, > > On 14 Jan 2016, at 06:07, Felix Yang <felix.y...@oracle.com> wrote: > >> Hi all, >> please review the fix for >> test/java/net/SocketPermission/SocketPermi

Re: RFR: 8147962: URL should handle lower-casing of protocol locale-independently

On 22/01/16 13:38, Claes Redestad wrote: On 2016-01-22 14:38, Alan Bateman wrote: On 22/01/2016 12:29, Claes Redestad wrote: : http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ Looks good. -Chris.

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

On 22/01/16 12:36, Mark Sheppard wrote: Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8147862/webrev/ Thanks for fixing this Mark. This was originally my mistake :-( -Chris. to address https://bugs.openjdk.java.net/browse/JDK-8147862 it was

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

and have the test run in othervm mode. I did do a complete test run with this change and it did not cause any problems, but then again the policy is all permissions! Thanks Felix. -Chris. > Otherwise it may affect other tests. Thanks, Felix On Jan 20, 2016, at 12:45 PM, Chris Hegarty <chri

Re: Patch for adding SO_REUSEPORT socket option

From: net-dev [mailto:net-dev-boun...@openjdk.java.net] On Behalf Of Lu, Yingqi Sent: Thursday, February 11, 2016 9:47 AM To: Alan Bateman ; Volker Simonis ; Michael McMahon Cc: Kaczmarek, Eric

Re: RFR 8148609: supportedOptions() methods return a mutable set

On 1 Mar 2016, at 09:45, Alan Bateman wrote: > On 01/03/2016 09:27, vyom wrote: >> Hi All, >> >> Please review my code changes for the below issue. >> >> Bug: JDK-8148609 : supportedOptions() methods return a mutable set >> Webrev:

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

On 1 Mar 2016, at 09:18, vyom wrote: > Hi All, > > Please review my code changes for testcase fix. > > Bug: JDK: Test test/java/net/InetAddress/getOriginalHostName.java fails to > load JavaNetInetAddressAccess from SharedSecrets > > Webrev:

Re: RFR 8151586: Wrong exception catch for FTPClient in JDK-8055032

Vyom, On 15/03/16 09:51, vyom wrote: Hi, Please review the below fix. Bug: JDK-8151586 : Wrong exception catch for FTPClient in JDK-8055032 Webrev :http://cr.openjdk.java.net/~rgoel/~vyom/8151586/webrev0.0/ The source change

Re: RFR: 8151299 Http client SelectorManager overwriting read and write events

Michael, This is a nasty bug. I agree with the notion of the attachment tracking the interest ops. Most of my comments are related to code-style, cleanup, and closing of resources by test. Rather than trying to list them I’ve included a webrev, generated against your patch. You can just import

Re: RFR: 8151441 TEST: java/net/httpclient/RequestBodyTest.java failing

On 8 Mar 2016, at 20:49, Michael McMahon wrote: > This is a small change, where an internal completion result > was getting lost. > > http://cr.openjdk.java.net/~michaelm/8151441/webrev.1/ The source changes look ok, maybe just line up the dots of the method

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

Hi Mark, This mainly looks good. Some specific comments on InetAddress. - Why did you add transient to this field? private static TRANSIENT NameService nameService = null; - There will be support for IPv6, right? There is a comment in the code that says otherwise. -

Re: RFR 7167293:FtpURLConnection connection leak on FileNotFoundException

gt;>>>> +// ignore; alternatively fe.addSuppressed(ioe); >>>>> +} >>>>> + } >>>>> throw new IOException(fe); >>>>> >>>>> Roger >>>>>

Re: RFR JDK-8087113: Websocket API and implementation

Simone, On 5 Apr 2016, at 20:25, Simone Bordet <simone.bor...@gmail.com> wrote: > Hi, > > On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: >>>> On 3 Apr 2016, at 18:43, Simone Bordet <simone.

Re: 8150234: Windows 10 App Containers disallow access to ICMP calls

I think this is fine Rob. -Chris. On 29 Mar 2016, at 15:38, Rob McKenna wrote: > Hi folks, > > Looking for a review for this change. > > Basically https://bugs.openjdk.java.net/browse/JDK-8135305 abandoned the old > TCP echo isReachable check in favour of Windows'

Re: RFR JDK-8153353: HPACK implementation

Pavel, Overall this is very good. I have mostly minor comments. > Though this is an implementation only package, it could use a few more > comments > to support maintainers. In the package.html, a couple of hints about what > classes are > the external interface would be useful and an

Re: RFR JDK-8153353: HPACK implementation

On 12 Apr 2016, at 17:51, Pavel Rappo wrote: > >> On 12 Apr 2016, at 16:56, Roger Riggs wrote: >> >> Since you have a TestHelper class you could put it there and not duplicate >> the code in several tests. > > Thanks! Done. > >

Re: RFR JDK-8087113: Websocket API and implementation

On 6 Apr 2016, at 09:37, Simone Bordet wrote: > Hi, > > On Tue, Apr 5, 2016 at 11:06 PM, Pavel Rappo wrote: >> Let's suppose we have a ByteBuffer to send. This ByteBuffer contains 1 MB of >> data, the socket send buffer is 16 KB, the network is

Re: RFR 8151586: Wrong exception catch for FTPClient in JDK-8055032

t; <http://cr.openjdk.java.net/%7Evtewari/8151586/webrev0.1/index.html> The source changes look fine. The test: you have just updated the output of an existing test. Do this test cover your changes already? Or have you forgotten to include the test updates? -Chris. > Thanks, > Vyom >

Re: JDK 9 RFR of JDK-8151260: Mark URLPermission/URLTest.java and ipv6tests/TcpTest.java as intermittently failing

Looks fine Amy. -Chris. On 8 Mar 2016, at 02:00, Amy Lu wrote: > Please review. > > Thanks, > Amy > > On 3/4/16 7:59 PM, Amy Lu wrote: >> Below tests are known to fail intermittently, this patch is to mark them >> accordingly with keyword 'intermittent'. >> >>

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

v0.1/index.html>). Looks good to me Vyom. -Chris. > Thanks, > Vyom > >> On Tuesday 01 March 2016 03:35 PM, Chris Hegarty wrote: >>> On 1 Mar 2016, at 09:18, vyom <vyom.tew...@oracle.com> wrote: >>> >>> Hi All, >>> >>>

Re: RFR 8148609: supportedOptions() methods return a mutable set

> On 2 Mar 2016, at 08:19, Alan Bateman wrote: > > > > On 02/03/2016 06:47, vyom wrote: >> Hi Chris/Alan, >> >> Thanks for review, please find the updated >> webrev(http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.1/index.html >>

Re: RFR 8148609: supportedOptions() methods return a mutable set

On 3 Mar 2016, at 09:39, Vyom Tewari <vyom.tew...@oracle.com> wrote: > i need sponsor for this fix. I will sponsor this for you. -Chris. > Vyom > > On 3/3/2016 2:37 PM, Alan Bateman wrote: >> >> >> On 03/03/2016 09:03, Chris Hegarty wrote: >>> O

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

On 3 Mar 2016, at 09:40, Vyom Tewari <vyom.tew...@oracle.com> wrote: > i need sponsor for this fix as well. I will sponsor this for you. -Chris. > Vyom > > On 3/3/2016 2:34 PM, Chris Hegarty wrote: >> On 3 Mar 2016, at 05:33, Vyom Tewari <vyom.tew...@oracle.com&g

Re: RFR 8148609: supportedOptions() methods return a mutable set

Vyom > > > On 3/2/2016 2:36 PM, Chris Hegarty wrote: >>> On 2 Mar 2016, at 08:19, Alan Bateman <alan.bate...@oracle.com> wrote: >>> >>> >>> >>> On 02/03/2016 06:47, vyom wrote: >>>> Hi Chris/Alan, >>>> >

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

On 3 Mar 2016, at 05:33, Vyom Tewari wrote: > incorporated the review comment, updated webrev in place. > > http://cr.openjdk.java.net/~nkumar/vyom/8150521/webrev0.1/index.html > Looks fine.

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

On 3 Mar 2016, at 09:40, Vyom Tewari <vyom.tew...@oracle.com> wrote: > i need sponsor for this fix as well. Pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eb5798a009cc -Chris. > Vyom > > On 3/3/2016 2:34 PM, Chris Hegarty wrote: >> On 3 Mar 2016, at 05:3

Re: RFR 8148609: supportedOptions() methods return a mutable set

Alan Bateman wrote: >> >> >> On 03/03/2016 09:03, Chris Hegarty wrote: >>> On 3 Mar 2016, at 05:36, Vyom Tewari <vyom.tew...@oracle.com> wrote: >>> >>>> please find the updated webrev >>>> >>>> http://cr.openjdk.java.net/~n

Re: RFR JDK-8087113: Websocket API and implementation

On 25 Mar 2016, at 16:21, Pavel Rappo wrote: > Hi, > > Could you please review my change for JDK-8087113 > > http://cr.openjdk.java.net/~prappo/8087113/webrev.03/ I’ve looked at the API a number of times, and overall I’m happy with it ( modulo the known open issues

Re: RFR JDK-8087113: Websocket API and implementation

I'm still working my way through the code, but ... On 04/04/16 15:02, Pavel Rappo wrote: Hi Simone, thanks for deep dive into this! On 3 Apr 2016, at 18:43, Simone Bordet wrote: Throwing exceptions. --- Given that the API is making use of CompletableFuture,

Re: RFR JDK-8087113: Websocket API and implementation

On 4 Apr 2016, at 17:00, Simone Bordet wrote: > Hi, > > On Mon, Apr 4, 2016 at 4:02 PM, Pavel Rappo wrote: >> I see your point. Yes, working asynchronously kind of suggests that we should >> relay all exceptions through the asynchronous

Re: RFR 7167293:FtpURLConnection connection leak on FileNotFoundException

On 29 Mar 2016, at 17:38, vyom <vyom.tew...@oracle.com> wrote: > On Tuesday 29 March 2016 09:10 PM, Chris Hegarty wrote: >> On 29 Mar 2016, at 16:20, Roger Riggs <roger.ri...@oracle.com> wrote: >> >>> Looks good, >> +1 >> >> Does the test ne

RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

One of the remaining open issues in JEP 200 [1] is that the base module exports the jdk.net package, thereby violating Principle 4 of JEP 200: a Java SE module must not export any non-SE API packages without qualification. http://cr.openjdk.java.net/~chegar/8044773/

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

enjdk.java.net/groups/build/doc/code-conventions.html > > On 2016-04-25 23:01, Chris Hegarty wrote: >> One of the remaining open issues in JEP 200 [1] is that the base module >> exports the jdk.net package, thereby violating Principle 4 of JEP 200: >> a Java SE module must not export a

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 26 Apr 2016, at 10:57, Erik Joelsson <erik.joels...@oracle.com> wrote: > > > On 2016-04-26 11:51, Chris Hegarty wrote: >> On 26 Apr 2016, at 10:35, Erik Joelsson <erik.joels...@oracle.com> wrote: >> >>> Hello Chris, >>> >>

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 26 Apr 2016, at 09:20, Alan Bateman <alan.bate...@oracle.com> wrote: > On 25/04/2016 22:01, Chris Hegarty wrote: >> One of the remaining open issues in JEP 200 [1] is that the base module >> exports the jdk.net package, thereby violating Principle 4 of JEP 200: >

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 27 Apr 2016, at 20:13, Alan Bateman <alan.bate...@oracle.com> wrote: > On 27/04/2016 10:04, Chris Hegarty wrote: >> On 26 Apr 2016, at 18:21, Alan Bateman <alan.bate...@oracle.com> wrote: >> >>> I took a second pass over it. One thing

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 27 Apr 2016, at 17:27, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> On Apr 27, 2016, at 2:04 AM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> >> This works out quite nice. Webrev updated in-place: >> http://cr.openjdk.java.ne

Re: RFR JDK-8151913: Fix module dependencies in java/net tests

On 27 Apr 2016, at 08:08, John Jiang wrote: > Hi, > Please review the fix for explicitly declaring module dependencies for java > net tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8151913 > Webrev: http://cr.openjdk.java.net/~jjiang/8151913/webrev.00 This

Re: RFR: 8087124 HTTP/2 implementation

On 22 Apr 2016, at 22:51, Michael McMahon wrote: > Hi, > > An updated webrev is available at: > > http://cr.openjdk.java.net/~michaelm/8087124/webrev.2/ > > The main change is the removal of the permanently allocated > two threads per TCP connection (for HTTP/2)

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 26 Apr 2016, at 18:21, Alan Bateman wrote: > I took a second pass over it. One thing that I'm wondering about is whether > BaseExtendedSocketOptions + Support should be collapsed into one abstract > class ExtendedSocketOptions (or better name) with 3 instance

Re: RFR 8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c

Looks good Vyom. I will sponsor this for you. -Chris > On 20 May 2016, at 09:50, vyom wrote: > > Hi, > > Please review the simple fix for below issue. > > Bug: JDK-8048520 :File Descriptor Leak in > jdk/src/solaris/native/java/net/net_util_md.c > > Webrev:

RFR [9] 8155086: Replace usage of -Djdk.launcher.limitmods in tests with -limitmods

Replace usage of -Djdk.launcher.limitmods, in several networking and NIO tests, with -limitmods now that jtreg with support for -limitmods is available. -Chris. diff --git a/test/java/net/SocketOption/OptionsTest.java b/test/java/net/SocketOption/OptionsTest.java ---

Re: JDK 9 RFR of JDK-8157499: Mark several tests from jdk_net as intermittently failing

On 23/05/16 07:39, Amy Lu wrote: Below tests are known to fail intermittently. This patch is to mark the test accordingly with keyword 'intermittent’ until issue resolved. java/net/MulticastSocket/TestInterfaces.java (JDK-8134989) java/net/DatagramSocket/PortUnreachable.java (JDK-8085875)

Re: RFR 8143923 :DatagramSocket and MulticastSocket supportedOptions set depends on call order

On 23/05/16 05:04, vyom wrote: Hi All, Please review the below code change. Bug : JDK-8143923 DatagramSocket and MulticastSocket supportedOptions set depends on call order Webrev : http://cr.openjdk.java.net/~vtewari/8143923/webrev0.0/index.html

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

k/net/Sockets/Test.java instead of creating a >> new one. >> Please see updated review: >> >> http://cr.openjdk.java.net/~snikandrova/8136933/webrev.03/ >> <http://cr.openjdk.java.net/%7Esnikandrova/8136933/webrev.03/> >> >> Thank you, >> S

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

> On 20 May 2016, at 14:10, Alan Bateman wrote: > > On 20/05/2016 14:05, Svetlana Nikandrova wrote: >> Alan, >> >> another test related to this option is on the same level >> (test/jdk/net/SocketFlow) I added this recently, when working on a different issue, when I

Re: RFR 8156801: java/net/httpclient/security/Driver.java failed with RuntimeException: Non zero return value

On 12 May 2016, at 14:43, Michael McMahon wrote: > This test is still failing intermittently. The reason is that one of the > places where BindException > can be thrown is called by reflection. So, the exception is wrapped in an > InvocationTargetException > and

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