RFR [9] 8139179: URLStreamHandler* should link to URL ctor that specifies how factories/providers are located

It was pointed out that the updated URL spec that describes how URL protocol handlers are located isn't prominent in the avadoc. In particular it was noted that it's not linked from URLStreamHandlerFactory or URLStreamHandlerProvider. Adding such links will make it clear how these classes tie t

Re: WebSocket client API

Pavel, > On 13 Oct 2015, at 10:40, Pavel Rappo wrote: > > Hi Simone, > >> On 8 Oct 2015, at 20:51, Simone Bordet wrote: >> >> The *API* should provide a callback to notify when the ByteBuffer has >> been consumed. > > Here is a proposed mechanism for managing buffers used by Listener. I thi

Re: RFR 8139373 : [TEST_BUG] java/net/MulticastSocket/MultiDead.java failed with timeout

Looks fine Ivan, Just a typo on: 48 Utils.adjustTimeout(CHILDREN_COUNT * CHILD_TIMEOT * 2); -Chris. On 21/10/15 11:06, Ivan Gerasimov wrote: Hello! A few failures of the recently added regtest were observed. The failures seem to be due to slow machines. The suggested fix is to 1) incr

Re: RFR 8131155/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java failed because of Teredo Tunneling Pseudo-Interface

> On 14 Dec 2015, at 6:53 a.m., Felix Yang wrote: > > Hi all, >please review the fix for > java/net/NetworkInterface/NetworkInterfaceStreamTest.java. It is necessary to > exclude "Teredo Tunneling Pseudo-Interface" whose configuration changes > frequently. > > Bug: https://bugs.openjdk.j

Re: RFR 8131155/9, java/net/NetworkInterface/NetworkInterfaceStreamTest.java failed because of Teredo Tunneling Pseudo-Interface

On 14/12/15 10:07, Paul Sandoz wrote: Hi Felix, Is it correct to filter out all network interfaces on windows platforms? I may be missing something, but this should ONLY filter out interfaces with the name 'Teredo', on Windows. NOT ALL. It is quite common for networking tests to exclude Tere

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

On 13 Nov 2015, at 04:59, Sebastian Sickelmann 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 Hegarty for an

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 also exclude > "Teredo Tun

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: http://cr.openjdk.java.net/~x

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 net-dev community. No objectio

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 > > Webrev: http://cr.openjdk.java.n

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. -Chris. > The java/net/SocketOpt

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

ising 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 wrote: Hi all, please review the fix for java/net/ipv6tests/TcpTest.java, which replaces hard-coded ports with dynamic free ports on ru

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: 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 microbenchmarks, while not > regressin

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 tha

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

> On 18 Jan 2016, at 16:20, Claes Redestad 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, >>>> >>>> please review t

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: https://bugs.openjdk.java.net/browse/JDK-8065076 > W

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

On 20 Jan 2016, at 06:36, Chris Hegarty wrote: > 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.

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 observed

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 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

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 Hega

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 known, well-behaved URLStreamHan

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

On 28 Jan 2016, at 16:38, Claes Redestad 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 comparison is >> being used for perf reas

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 >> >> passes again with this change

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). http://cr.openjdk.java.net/~micha

Re: [PING] RFR: JDK-8135259: InetAddress.getAllByName only reports "unknown error" instead of actual cause

On 12/02/16 11:09, Ramanand Patil wrote: Hi Sean, Since I saw the convention of filenames being a bug id, I had created a new test. :) Anyways, I have updated the existing test with my bug id. Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8135259/webrev.02/ The changes look

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 ; Viswanathan, Sandhya ; Kharbas, Kishor ; Aundhe, Shirish ; net-dev@openjdk.java.net Subject: RE:

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: http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.0/ >>

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: http://cr.openjdk.java.net/~nkumar/vyom/815

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

ks 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 wrote: >>> >>> Hi All, >>> >>> Please review my code changes for testcase fix. >&g

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 05:36, Vyom Tewari wrote: > please find the updated webrev > > http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/ > <http://cr.openjdk.java.net/%7Enkumar/vyom/8148609/webrev0.2/> Looks fine. -Chris. > Thanks, > Vyom > > > On 3/2/

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. -Chris. > Vyom > > On 3/2/

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

On 3 Mar 2016, at 09:39, Vyom Tewari 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: >>> On 3 Mar 2016, at 05:36, Vyom T

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 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 wrote: >> >>> incorporated the review

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

>> On 03/03/2016 09:03, Chris Hegarty wrote: >>> On 3 Mar 2016, at 05:36, Vyom Tewari wrote: >>> >>>> please find the updated webrev >>>> >>>> http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/ >>>> <http://

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 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:33, Vyom Tewari wrote: >> >

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'. >> >> java/net/URLPermission/URLTest

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

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 invocations of sendBodyAsync and the

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 lo

Re: RFR 7167293:FtpURLConnection connection leak on FileNotFoundException

Vyom, On 15/03/16 10:00, vyom wrote: Hi, Please review the below fix. Bug: JDK-7167293 : FtpURLConnection connection leak on FileNotFoundException Webrev: http://cr.openjdk.java.net/~rgoel/~vyom/7167293/webrev0.0/ You have the

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. - jdk.net.hos

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

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 > > On Tuesday 15 March 2

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

On Thursday 17 March 2016 02:17 PM, Chris Hegarty wrote: On 17 Mar 2016, at 06:57, vyom wrote: Hi Chris, thanks for review, please find the updated webrev. I updated the existing test case to cover this issue. http://cr.openjdk.java.net/~vtewari/8151586/webrev0.1/index.html <http://cr.open

Re: RFR 7167293:FtpURLConnection connection leak on FileNotFoundException

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

Re: RFR 7167293:FtpURLConnection connection leak on FileNotFoundException

On 29 Mar 2016, at 17:38, vyom wrote: > On Tuesday 29 March 2016 09:10 PM, Chris Hegarty wrote: >> On 29 Mar 2016, at 16:20, Roger Riggs wrote: >> >>> Looks good, >> +1 >> >> Does the test need to be run in othervm mode ? > I don't think oth

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 ). Some initial comments.

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, throwing exceptions instead is in

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 interface (CF in this >> particular >> case), simply bec

Re: RFR JDK-8087113: Websocket API and implementation

Simone, On 5 Apr 2016, at 20:25, Simone Bordet wrote: > Hi, > > On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty > wrote: >>>> On 3 Apr 2016, at 18:43, Simone Bordet wrote: >>>> Threading. >>>> --- >>>> WebSocket.sendXXX

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' ICMP calls on supported >

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 not particularly fast. >> Suppose then the first

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. > > http://cr.openjdk.java.net/~prappo/8153353/webrev.00/test/java

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 example

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: http://cr.openjdk.java.net/~redestad/81541

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

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

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

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 18/04/16 11:09, Claes Redestad wrote: On 04/18/2016 12:06 PM, Chris Hegarty wrote: 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

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 Th

Re: RFR JDK-8153353: HPACK implementation

On 18/04/16 15:30, Pavel Rappo wrote: On 13 Apr 2016, at 10:10, Chris Hegarty wrote: A general comment; Quite a number of classes, especially Encoder and Decoder, would benefit from a few relatively lightweight comments, e.g. IntegerReader I would like to address it after the initial push

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'. > > I used '\n' as a lin

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 Solaris host which has vi

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 reviewed. -Chris. > Regards, >

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/ https://bugs.openjdk.java.net/b

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 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: >> a Java SE module must not

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

ntions.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 any non-SE API packages witho

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 wrote: > > > On 2016-04-26 11:51, Chris Hegarty wrote: >> On 26 Apr 2016, at 10:35, Erik Joelsson wrote: >> >>> Hello Chris, >>> >>> In general it looks good. >> Thanks for the review Erik. >

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 looks ok to me. Thanks,

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 methods and 2 > static methods

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) This is good. Http2ClientImp

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 wrote: > >> On Apr 27, 2016, at 2:04 AM, Chris Hegarty wrote: >> >> This works out quite nice. Webrev updated in-place: >> http://cr.openjdk.java.net/~chegar/8044773/jdk/ > > One comment on the qualified exports of sun.

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 wrote: > On 27/04/2016 10:04, Chris Hegarty wrote: >> 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

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 --- a/src/java.

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 mor

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

On 4 May 2016, at 23:59, Michael McMahon wrote: > I've just updated the webrev at > > http://cr.openjdk.java.net/~michaelm/8155928/webrev.3 > > to retry the tests in the unlikely event of a BindException Thanks Michael. This looks ok. -Chris. > - Michael >

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 8155621, which I assume

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 modifications and to process them

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

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 this area. I agree with the

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. This is done elsewhere in thi

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

ly 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] >> Sent: Mittwoch, 11. Mai

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 needs to be unwrapped. > > htt

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 cha

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

34. So maybe this part for OpenBSD could be removed. > It would change the include order on OpenBSD, of course. As I don't have an > OpenBSD build environment I decided not to touch this but you could remove it > if you have more confidence... > > Best regards > Ch

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 mod

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

12 May 2016 09: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

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

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 wrote: >>> Hi, >>> >>&g

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

ed. 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 wrote: >> >>> Hi Chris, >>> >>> Please find the updated >>

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

s, > Vyom > > > On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote: >> On 17 May 2016, at 10:48, vyom wrote: >> >>> Hi Chris, >>> >>> Please find the updated >>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html

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: http://cr.openjdk.java.net/~vtewa

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 noticed that there were no

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

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

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 --- a/test/java/net/SocketOptio

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

va 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, >> Svetlana >> >> On

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

<    1   2   3   4   5   6   7   8   9   10   >