Re: RFR: 8286873: Improve websocket test execution time [v3]

On Thu, 19 May 2022 12:05:45 GMT, Daniel Jeliński wrote: >> This PR improves the execution time of jdk_net tests (and, by extension, >> tier2) by about 3 minutes. >> >> Tests located under `jdk/java/net/httpclient/websocket` are never run in >> parallel. Each of the 8 modified `Pending***`

Re: RFR: 8286873: Improve websocket test execution time [v2]

On Thu, 19 May 2022 09:42:05 GMT, Daniel Jeliński wrote: > > What looks questionable is rearrangement of asserts: when `assertHangs` > > moves down. assertNotDone(cfClose) can transitorry pass even if ping has > > not hung. > > `assertHangs` either waits for 5 seconds or throws an exception,

Re: RFR: 8286873: Improve websocket test execution time

On Tue, 17 May 2022 12:45:52 GMT, Daniel Jeliński wrote: > This PR improves the execution time of jdk_net tests (and, by extension, > tier2) by about 3 minutes. > > Tests located under `jdk/java/net/httpclient/websocket` are never run in > parallel. Each of the 8 modified `Pending***` tests

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v9]

On Thu, 12 May 2022 14:56:47 GMT, Daniel Fuchs wrote: >> In relation to >> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find >> here a patch that addresses possibly lossy conversions in java.net.http > > Daniel Fuchs has updated the pull request incrementally with

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v9]

On Thu, 12 May 2022 14:15:43 GMT, Daniel Fuchs wrote: >>> OK - I will change codeLengthOf as suggested. It was not immediately >>> obvious to me that the values would fit in the first 31 bits. >> >> In fact, it would even fit into the first 30 bits. There's a top-level >> comment that

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v6]

On Thu, 12 May 2022 10:05:14 GMT, Daniel Fuchs wrote: > OK - I will change codeLengthOf as suggested. It was not immediately obvious > to me that the values would fit in the first 31 bits. In fact, it would even fit into the first 30 bits. There's a top-level comment that explains the layout

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v5]

On Thu, 12 May 2022 10:08:23 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java >> line 291: >> >>> 289: >>> 290: HeaderWriter noMask() { >>> 291: // The negation "~" sets the high order bits >> >> Rubber-stamping this

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v6]

On Thu, 12 May 2022 10:51:04 GMT, Daniel Fuchs wrote: >> In relation to >> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find >> here a patch that addresses possibly lossy conversions in java.net.http > > Daniel Fuchs has updated the pull request incrementally with

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v5]

On Wed, 11 May 2022 18:42:46 GMT, Daniel Fuchs wrote: >> In relation to >> [JDK-8244681](https://bugs.openjdk.java.net/browse/JDK-8244681), please find >> here a patch that addresses possibly lossy conversions in java.net.http > > Daniel Fuchs has updated the pull request incrementally with

Re: RFR: 8286386: Address possibly lossy conversions in java.net.http [v5]

On Thu, 12 May 2022 08:56:26 GMT, Daniel Fuchs wrote: >> No because the int returned could be negative, while the long will not. >> Assuming bufferLen is 0 and codeLengthOf() returns some value that has the >> 32th bit set to 1 then when codeLengthOf() returns long, bufferLen + >>

Re: RFR: 8284893: Fix typos in java.base

On Fri, 15 Apr 2022 11:25:09 GMT, Pavel Rappo wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those >> changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >

Re: RFR: 8284893: Fix typos in java.base

On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in

Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build

On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain

Re: RFR: JDK-8280492: Address remaining doclint issues in JDK build

On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote: > LGTM. I hope in the future IDEs will pick that rule up and offer some help > when writing `{@link }` `@see`... They will do it quicker, if you create new or support existing bugs in their bug trackers. - PR:

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it en > masse? > > As far as I remember, the first mass-canonicalization of

Re: RFR: 8276401: Use blessed modifier order in java.net.http

On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote: > Hi, > > Please find here a trivial cleanup change that updates classes in the > `java.net.http` module to use the "blessed modifier order". > > The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh >

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote: >>> Pragmatically, fix the script to ignore those keywords on comment lines. >>> Learn Perl, its just a regular expression pattern match and replace >>> expression. >> >> I understand in principle how to modify that script to ignore doc

Integrated: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it en > masse? > > As far as I remember, the first mass-canonicalization of

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 19:22:15 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: >> >>> 86: */ >>> 87: public >>> 88: abstract class CallSite { >> >> I think it's better to move all modifiers

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 19:15:26 GMT, Andrey Turbanov wrote: >> This PR follows up one of the recent PRs, where I used a non-canonical >> modifier order. Since the problem was noticed [^1], why not to address it at >> mass? >> >> As far as I remember, the first mass-canonicalization of modifiers

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 18:48:20 GMT, Roger Riggs wrote: > Pragmatically, fix the script to ignore those keywords on comment lines. > Learn Perl, its just a regular expression pattern match and replace > expression. I understand in principle how to modify that script to ignore doc comments. The

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 17:45:07 GMT, Pavel Rappo wrote: >>> In comments, I think the 'synchronized static 'reads better, the >>> conventional order is for the code. >> >> I think Roger is right and maybe the change to the javadoc could be dropped >> from this

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 17:39:17 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Object.java line 282: >> >>> 280: * For objects of type {@code Class,} by executing a >>> 281: * static synchronized method of that class. >>> 282: * >> >> In comments, I think the

Re: RFR: 8276348: Use blessed modifier order in java.base

On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote: > This PR follows up one of the recent PRs, where I used a non-canonical > modifier order. Since the problem was noticed [^1], why not to address it at > mass? > > As far as I remember, the first mass-canonicalization of modif

RFR: 8276348: Use blessed modifier order in java.base

This PR follows up one of the recent PRs, where I used a non-canonical modifier order. Since the problem was noticed [^1], why not to address it at mass? As far as I remember, the first mass-canonicalization of modifiers took place in JDK-8136583 in 2015 [^2]. That change affected 1780 lines

Re: RFR: JDK-8275518: accessibility issue in Inet6Address docs

On Tue, 19 Oct 2021 13:50:20 GMT, Ludvig Janiuk wrote: > Single-row table was being used as a hack here, a description list > seems more appropriate Would it be possible to build documentation for that page to see how it looks? - PR: https://git.openjdk.java.net/jdk/pull/6010

Re: RFR: 8274809: Update java.base classes to use try-with-resources

On Wed, 6 Oct 2021 16:00:41 GMT, Bradford Wetmore wrote: >> 8274809: Update java.base classes to use try-with-resources > > src/java.base/share/classes/sun/security/timestamp/HttpTimestamper.java line > 127: > >> 125: // Receive the reply >> 126: byte[] replyBuffer = null; >>

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov wrote: > Pass "cause" exception as constructor parameter is shorter and easier to read. This will need to be thoroughly tested to make sure there were no implicit dependencies on now-removed happens-before edges (`initCause` is synchronized).

Integrated: 8273616: Fix trivial doc typos in the java.base module

On Fri, 10 Sep 2021 21:16:19 GMT, Pavel Rappo wrote: > 8273616: Fix trivial doc typos in the java.base module This pull request has now been integrated. Changeset: b4b12101 Author: Pavel Rappo URL: https://git.openjdk.java.net/jdk/commit/b4b121018d16e531f3a51ff75ae37fdc374d5

Re: RFR: 8273616: Fix trivial doc typos in the java.base module [v3]

> 8273616: Fix trivial doc typos in the java.base module Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Use "ensure" instead of "insure" - Changes: - all: https://git.openjdk.java.net/jdk/

Re: RFR: 8273616: Fix trivial doc typos in the java.base module [v2]

On Fri, 10 Sep 2021 23:20:11 GMT, Pavel Rappo wrote: >> 8273616: Fix trivial doc typos in the java.base module > > Pavel Rappo has updated the pull request incrementally with one additional > commit since the last revision: > > Revert two fixes Thanks to those who revi

Re: RFR: 8273616: Fix trivial doc typos in the java.base module [v2]

> 8273616: Fix trivial doc typos in the java.base module Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision: Revert two fixes - Changes: - all: https://git.openjdk.java.net/jdk/pull/5475/files - new: ht

Re: RFR: 8273616: Fix trivial doc typos in the java.base module [v2]

On Fri, 10 Sep 2021 21:52:36 GMT, John R Rose wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert two fixes > > src/java.base/share/classes/java/nio/channels/FileCh

RFR: 8273616: Fix trivial doc typos in the java.base module

8273616: Fix trivial doc typos in the java.base module - Commit messages: - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/5475/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5475=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273616 Stats: 55

Re: RFR: 8266250: WebSocketTest and WebSocketProxyTest call assertEquals(List, List) [v3]

On Thu, 29 Apr 2021 11:28:26 GMT, Daniel Fuchs wrote: >> Please find here an almost trivial test fix that should improve diagnostic >> in case of failures. >> It also avoids relying on an unspecified behavior of `Assert.assertEquals`. > > Daniel Fuchs has updated the pull request incrementally

Re: RFR: 8266250: WebSocketTest and WebSocketProxyTest call assertEquals(List, List)

On Thu, 29 Apr 2021 09:03:31 GMT, Daniel Fuchs wrote: > Exactly - that API specification doesn't say whether elements > that are arrays will be compared using shallow equals or deep > equals. Fair enough. Since you are here, consider further improving diagnosability. The failed comparison

Re: RFR: 8266250: WebSocketTest and WebSocketProxyTest call assertEquals(List, List)

On Wed, 28 Apr 2021 21:22:23 GMT, Daniel Fuchs wrote: > It also avoids relying on an unspecified behavior of `Assert.assertEquals`. Which behavior is that? If I recall correctly, the test was written for TestNG 6.9.5, which provides a [method to compare

Integrated: 8255989: Remove explicitly unascribed authorship from Java source files

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote: > This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters This pull request

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files [v2]

On Sat, 7 Nov 2020 09:05:29 GMT, Sergey Bylokhov wrote: >> Pavel Rappo has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request conta

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files [v2]

> This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters Pavel Rappo has updated the pull request with a new target base due to a merge

RFR: 8255989: Remove explicitly unascribed authorship from Java source files

This PR proposes to remove 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown` 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters - Commit messages: - Initial commit Changes:

Re: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection [v2]

On Fri, 2 Oct 2020 08:41:56 GMT, Conor Cleary wrote: >> This patch replaces a LinkedList data structure used in the >> net.http.Http2Connection class with an ArrayList. This >> issue relates to [JDK-8246048: Replace LinkedList with ArrayLists in >>

Re: RFR: 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher. [v6]

On Mon, 5 Oct 2020 11:02:55 GMT, Daniel Fuchs wrote: >> Daniel, I believe Chris' concern is the escape of `this` before the >> (`AggregateSubscription`) object is fully >> constructed. > > Sorry - where does it escape? It doesn't escape anywhere. We have used this > idiom everywhere where a

Re: RFR: 8252374: Add a new factory method to concatenate a sequence of BodyPublisher instances into a single publisher. [v6]

On Mon, 5 Oct 2020 09:40:14 GMT, Daniel Fuchs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java >> line 569: >> >>> 567: this.bodies = new ConcurrentLinkedQueue<>(bodies); >>> 568: this.subscriber = subscriber; >>> 569:

Re: RFR: 8253179: Replace LinkedList Impl in net.http.Http2Connection

On Thu, 1 Oct 2020 10:31:58 GMT, Conor Cleary wrote: >> Good point Aleksey. I guess that the original intent was to avoid >> `ConcurrentModificationException`. However I see that >> `streams` is a `ConcurrentHashMap` now. So maybe we could dispense of the >> copy: >> `private final Map>

Re: 8249786: java/net/httpclient/websocket/PendingPingTextClose.java fails very infrequently

Daniel, The changes in TransportImpl look okay to me. I cannot see how they break anything. On the other hand, I guess it will take some time to see if the (complete) changeset fixes the issue. One minor thing that makes me a tad bit uncomfortable is the new assert statements. Firstly, they

Re: RFR 8245245 : WebSocket can loose the URL encoding of URI query parameters

Looks good to me. P.S. I think I began to forget the very code I wrote. > On 26 Jun 2020, at 18:18, Daniel Fuchs wrote: > > I concur. Rahul has convinced me. > Rahul also pointed me to a test that verifies that the IAE is > thrown, so I believe that >

Re: RFR 8245245 : WebSocket can loose the URL encoding of URI query parameters

ote: > > > >> On 26 Jun 2020, at 14:38, Pavel Rappo wrote: >> >> Rahul, >> >> Won't that start retaining the URL fragment? From >> https://tools.ietf.org/html/rfc6455#section-3 >> >> Fragment identifiers are meaningless in the cont

Re: RFR 8245245 : WebSocket can loose the URL encoding of URI query parameters

Rahul, Won't that start retaining the URL fragment? From https://tools.ietf.org/html/rfc6455#section-3 Fragment identifiers are meaningless in the context of WebSocket URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of

Re: RFR 8240666: Websocket client’s OpeningHandshake discards the HTTP response body

An assertion of the form assertEquals(true, ((String)wse.getResponse().body()).contains("404")); looks odd. I'd suggest using any of assertTrue(boolean condition) assertTrue(boolean condition, String message) -Pavel > On 6 May 2020, at 14:12, Rahul wrote: > >

Re: Need sponsor to fix Javadoc warnings

those changes, you may want to ask ICU4J [^1] folk to incorporate them. If they agree, one day those changes may show up in the OpenJDK. -- [^1]: https://github.com/unicode-org/icu/tree/master/icu4j > On 15 Apr 2020, at 12:06, Pavel Rappo wrote: > > Vipin, > > I saw that

Re: Need sponsor to fix Javadoc warnings

the cumulative webrev: http://cr.openjdk.java.net/~prappo/8242366/webrev.01/ -Pavel > On 11 Apr 2020, at 20:23, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 9, 2020, at 2:45 AM, Pavel Rappo wrote: >> >> If your new patch addresses a similar type of proble

Re: Need sponsor to fix Javadoc warnings

If your new patch addresses a similar type of problem, please send it in reply to this email, so that I could merge it with the existing patch. Let's try to minimize process overhead if possible. > On 8 Apr 2020, at 17:35, Vipin Sharma wrote: > > > >> On Apr 8, 2020, at 6:

Re: Need sponsor to fix Javadoc warnings

Why assume something that sophisticated where it can be adequately explained by a simpler thing? :) I bet it was an IDE inspection. -Pavel > On 8 Apr 2020, at 14:14, Alan Bateman wrote: > > On 08/04/2020 14:07, Daniel Fuchs wrote: >> Hi Pavel, >> >> On 08/04/2020 13:56, David Holmes wrote:

Re: Need sponsor to fix Javadoc warnings

that can be, I still wouldn't do it in this changeset. -Pavel > On 8 Apr 2020, at 13:56, David Holmes wrote: > > Hi Pavel, > > Not a review ... > > On 8/04/2020 9:50 pm, Pavel Rappo wrote: >> Vipin, here you go: >> https://bugs.openjdk.java.n

Re: Need sponsor to fix Javadoc warnings

> On 7 Apr 2020, at 19:50, Vipin Sharma wrote: > > Hi Pavel, > >> On Apr 7, 2020, at 11:11 PM, Pavel Rappo wrote: >> >> I assume you have signed the OCA [1]. If not and you want to continue, >> please do it. If you've already done so, which is probably

Re: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent indents, etc. (net and nio)

~igerasim/8241760/01/webrev/ > > With kind regards, > > Ivan G. > > > On 3/29/20 2:43 PM, Pavel Rappo wrote: >> Ivan, >> >> 1. ByteBuffered has an awkwardly looking top-level doc comment >> markup/formatting. >> The "payload" begins on the same l

Re: [15] RFR 8241760 : Typos: empty lines in javadoc, inconsistent indents, etc. (net and nio)

Ivan, 1. ByteBuffered has an awkwardly looking top-level doc comment markup/formatting. The "payload" begins on the same line as the /** marker. Also, the tag is weirdly placed. Since you have fixed similar issues already (URLConnection), you could probably do the same here. Your call. 2. I

RFR [15] 8237817: Clean up net-properties.html

Hello, Please review the following change for https://bugs.openjdk.java.net/browse/JDK-8237817: http://cr.openjdk.java.net/~prappo/8237817/webrev.00/ Below are some explanations and reasoning behind the change. 1. Not only do the things that are marked up as "code" have a different look,

Re: RFR: 8236859: WebSocket over authenticating proxy fails with NPE

I think the WebSocket part of the changeset look good to me. I have gone through the non-WebSocket part of the changes shallowly. I'm not an expert. > On 14 Jan 2020, at 17:59, Daniel Fuchs wrote: > > Hi Pavel, > > On 14/01/2020 17:54, Pavel Rappo wrote: >> That changeset

Re: RFR: 8236859: WebSocket over authenticating proxy fails with NPE

That changeset applies fine, thanks. I was wondering what you had in mind when added OpeningHandshake:225. Was it for general robustness or you ran into something in particular? > On 14 Jan 2020, at 15:36, Daniel Fuchs wrote: > > On 14/01/2020 15:14, Daniel Fuchs wrote: >> I wonder if this

Re: RFR: 8236859: WebSocket over authenticating proxy fails with NPE

sing issue with the import. > (the patch is obtained by hg diff, not hg export) > > best regards, > > -- daniel > > On 14/01/2020 14:39, Pavel Rappo wrote: >> Daniel, >> I imported the patch from the link you provided as follows: >> hg import --no-com

Re: RFR: 8236859: WebSocket over authenticating proxy fails with NPE

Daniel, I imported the patch from the link you provided as follows: hg import --no-commit open.patch The patch applied successfully. I tried then to run the tests and saw that some of them could not be compiled. For instance, java/net/httpclient/websocket/BlowupOutputQueue.java

Fwd: HTTP/2 Support in com.sun.net.httpserver?

Forwarding to a more relevant mailing list. When answering, please remove jdk-dev from the list of recipients. Thanks. > Begin forwarded message: > > From: Chris Mason > Subject: HTTP/2 Support in com.sun.net.httpserver? > Date: 4 December 2019 at 18:02:30 GMT > To: "jdk-...@openjdk.java.net"

Re: [java.net.http.HttpClient] Active monitoring of resolved IP addresses

A more appropriate mailing list would be net-dev (cc'ed). When replying, please remove jdk-dev from the addressees. > On 7 Nov 2019, at 14:24, Nicolas Henneaux wrote: > > Hi, > > > > I am not sure it is the right mailing list. If it’s not, I apologize in > advance and could you tell me which

Re: RFR [14] 8232367: Update the jdk/java/net/httpclient tests to RS TCK 1.0.3

Chris, Which commit is this update based on? I think this is worth mentioning for the future maintainers. We supplied this information when we made the initial push: https://mail.openjdk.java.net/pipermail/net-dev/2019-June/012810.html -Pavel > On 1 Nov 2019, at 17:11, Chris Hegarty

Re: RFR[8217825]: Verify @AfterTest is used correctly in WebSocket tests

Patrick, Thank you for taking care of that! Before you push, please add missing spaces to WebSocketTest.java:612 WebSocketTest.java:713 (no need to update the webrev) Nits: WebSocketTest.java:808 does not abort WebSocket. Now, I understand that in normal circumstances we never expect

Re: RFR: 8228970: AssertionError in ResponseSubscribers$HttpResponseInputStream

May I suggest using org.testng.Assert.assertThrows instead of hand-rolled try-catch constructs in the test? > On 6 Aug 2019, at 11:12, Patrick Concannon > wrote: > > Hi, > > Would it be possible to have my fix for JDK-8228970 reviewed? > > The fix modifies the read(byte[], int, int) method

Re: RFR [14] 8226303: Test convenience reactive primitives from java.net.http with RS TCK

> On 2 Jul 2019, at 13:46, Daniel Fuchs wrote: > > Thanks for doing that! LGTM. I've pushed the change http://hg.openjdk.java.net/jdk/jdk/rev/3ae57bbf9585 For the record. In addition to what we've discussed I had to fix the TCK source by making it compliant with jcheck. That extra fix

Re: RFR [14] 8226303: Test convenience reactive primitives from java.net.http with RS TCK

, the BodyPublishersOfFile test exercises the BodyPublisher obtained by calling BodyPublishers.ofFile(Path) the BodySubscribersOfFile test exercises the BodySubscriber obtained by calling BodySubscribers.ofFile(Path) > On 1 Jul 2019, at 12:19, Pavel Rappo wrote: > >> On 25 Jun 20

Re: RFR [14] 8226303: Test convenience reactive primitives from java.net.http with RS TCK

> On 25 Jun 2019, at 15:27, Daniel Fuchs wrote: > > Would it be possible to add a one-line comment at the beginning > of each test to explain what they are testing? Thanks for taking a look at that! To be honest that's one of those cases where adding what you ask is like putting a sticker

RFR [14] 8226303: Test convenience reactive primitives from java.net.http with RS TCK

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8226602/webrev.00/ This change adds reactive streams conformance testing of convenience primitives exposed by java.net.http.HttpClient. The TckDriver.java file from the webrev provides some explanation on the

Re: RFR [14] 8226303: Examine the HttpRequest.BodyPublishers for exception handling

it * @bug 8226303 Is that okay? 2) Done. Thanks. > On 18 Jun 2019, at 16:07, Chris Hegarty wrote: > > [ adding net-dev ] > > Pavel, > >> On 18 Jun 2019, at 14:22, Pavel Rappo wrote: >> >> Hello, >> >> Please review the following change: &

Re: RFR [14] 8225583: Examine the HttpResponse.BodySubscribers for null handling

Looks good to me. > On 17 Jun 2019, at 18:00, Chris Hegarty wrote: > > I moved the null check to after the signal to the downstream > subscriber. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/8225583/webrev.01/ > > -Chris.

Re: RFR [14] 8225583: Examine the HttpResponse.BodySubscribers for null handling

> On 13 Jun 2019, at 17:57, Daniel Fuchs wrote: > > I'd prefer to remove: > 958 Objects.requireNonNull(throwable); But it seems to be the crux of that change. The tests accompanying this change verifies that behavior.

Re: RFR [14] 8225583: Examine the HttpResponse.BodySubscribers for null handling

Given the changes in PublishingBodySubscriber.onError, do we still need this null check? 884 private void signalError(Throwable err) { 885 if (err == null) { 886 err = new NullPointerException("null throwable"); 887 } 888

Re: [RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

I ran that changed test on Solaris many times. Those runs included some of the machines on which the previous incarnation failed. The runs were successful. Other platforms looked fine too. Looks good. > On 23 May 2019, at 18:19, Arthur Eubanks wrote: > > bug:

Re: IPv6 multicast binding (Bugs: JDK-8210493 JDK-8215294)

We are currently investigating a more constrained fix for 8210493. I'll get back to this list once it becomes clear(er) how to proceed. > On 2 May 2019, at 08:44, Andre Naujoks wrote: > > Hello all. > > I just noticed, that the fix from Bug JDK-8210493 was reverted for Java > 12. With a new

[ipv6] On updating certificates in tests

Arthur, Some time ago Chris mentioned [1] that there was at least one test failing due to missing SANs in its certificates: test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java You then replied that your were planning to address that issue in a future change.

Re: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers

> On 25 Jan 2019, at 17:04, Chris Hegarty wrote: > > I moved the code to common.Utils, to avoid any unnecessary dependency. Thanks. >> 2. Why does this change add server.close() to each and every test method of >> WebSocketTest? If I'm not mistaken that's what @AfterTest public void >>

Re: RFR [13] 8217429: WebSocket over authenticating proxy fails to send Upgrade headers

Chris, thanks for doing this! I have two questions on this change. 1. After this change has been applied, there will be a circular dependency between HttpRequestImpl and OpeningHandshake. If this code is used by these two classes maybe we are better off extracting it into some (already existing)

RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8215292/webrev.00 That change backs out the fix for "Bind to node- or linklocal ipv6 multicast address fails" [1]. The change in question is produced as: hg diff -c 23b3a46fa159 --reverse --git After I have

Re: JDK 12 RFR of JDK-8213911: Use example.com in java.net and other examples

Looks good to me. -Pavel

Re: RFR: 8214295: Populate handlers while holding streamHandlerLock

> On 26 Nov 2018, at 12:12, Seán Coffey wrote: > > JDK-8213942 synchronization fix can be improved Looks like a soft language for what actually is a race condition. I wonder at what point should we just rewrite the thing as Alan mentioned using "fully concurrent lookups"? -Pavel

Re: RFR: 8213942:URLStreamHandler initialization race

This fix assumes handlers returned from defaultFactory are interchangeable and that defaultFactory is thread-safe. If these assumptions are valid, looks good to me. > On 21 Nov 2018, at 14:31, Chris Hegarty wrote: > > >> On 21/11/18 13:04, Seán Coffey wrote: >> Thanks to all for the

Re: RFR: 8213942:URLStreamHandler initialization race

> On 20 Nov 2018, at 17:55, Seán Coffey wrote: > > Access to the handlers Hashtable and the factory should be made while holding > the streamHandlerLock lock I'm not sure about that. I wouldn't go with coarsening this lock's region. I would rather go with an additional check for handler being

Re: RFR [12] 8213490: Networking area nano cleanup

Unfortunately, this train has already gone. However, we can always create a new issue. > On 14 Nov 2018, at 01:03, Ivan Gerasimov wrote: > > Also, in > > src/java.base/windows/classes/sun/net/dns/ResolverConfigurationImpl.java > > -// Addreses have changed > +// Addresses have

Re: A parallel HttpClient sendAync question

> On 13 Nov 2018, at 02:35, Weijun Wang wrote: > > I'm scanning a file and downloading links inside: > > lines.flapMap(x -> Stream.ofNullable(findURIFrom(x))) > .map(l -> download(c, l)) > .forEach(f -> f.join()); > > CompletableFuture> download(HttpClient c, URI link) { >return

Re: RFR [12] 8213490: Networking area nano cleanup

> On 13 Nov 2018, at 00:35, Ivan Gerasimov wrote: > > Do you want to change ie. -> i.e. here as well: > > src/java.base/windows/native/libnet/net_util_md.c > > - * 2. If the reqeusted port is 0 (ie. any port) then we try to bind in v4 > space > + * 2. If the requested port is 0 (ie. any

Re: RFR [12] 8213490: Networking area nano cleanup

Daniel, Alan, I excluded the update from the draft to the RFC and created a separate bug for it: [P5] 8213757: Investigate the possibility of updating the reference to the spec in java.net.Inet6Address I added the changes to the URI class from JDK-8213490, which then effectively became a

Re: RFR [12] 8213490: Networking area nano cleanup

> On 12 Nov 2018, at 18:14, Alan Bateman wrote: > > It will need a CSR because it changes Inet6Address to specify that it can be > extended with scoped addresses described by RFC 4007. It might need analysis > to understand the differences between the draft and RFC 4007 (just in case it >

RFR [12] 8213490: Networking area nano cleanup

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8213490/webrev.00 This change is all about typos in javadoc, variables' names and comments. Once again, not only does this change addresses aesthetic issues, it also helps with searches. As always with this type of

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

Alan, Chris, Thanks for reviewing this change. However, before the push I tested it again and found out that there is a small number of Linux machines on which both tests fail. The only thing I found to be in common between these machines was the version of the Linux kernel. Machines with the

Re: RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

> On 7 Nov 2018, at 15:22, Alan Bateman wrote: > > Does the comment at L806 need to be updated? Also the change makes me > wondering about the 2.4 kernel support, maybe it is time to think about > dropping some of the older code path. Alan, Is that better?

RFR [12] 8210493: Bind to node- or linklocal ipv6 multicast address fails

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8210493/webrev.00 This change fixes binding to interface-local and link-local IPv6 multicast addresses on Linux. Thanks, -Pavel

RFR [12] 8212000: Verify exported symbols in java.base (libnet, libnio/ch)

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8212000/webrev.00/8212000/ This is a clean-up kind of change. It seals unnecessarily exported functions from libnet and libnio, and also removes an unused declaration from libnet. This change has been built and

Re: HttpClient API usage feedback/questions

> On 2 Jun 2018, at 07:22, Jaikiran Pai wrote: > > Some of the places where we parse the (response) headers, we check for the > presence of some headers and if not present then we default them to certain > values (based on certain application specific context). In its current form > of the

Re: NullPointerException in jdk.incubator.http.internal.hpack.HeaderTable.Table

A note for the readers of this mailing list. Apologies as this email has not been visible for quite a while (it was sent on 2018-03-31 and appeared on the list only on 2018-05-28). However, I have contacted the author and with his great help the issue was resolved on the 5th of April. The patched

Re: websockets

Hello Rossen, > On 22 Feb 2018, at 02:51, Rossen Stoyanchev wrote: > > ​​hi, > > > Simone Bordet: > > As the WebSocket APIs were moved to incubation and are now slated > > for JDK 11, it may be worth considering again whether it's the > > case to provide a Flow-based

Re: WebSocket

> On 20 Feb 2018, at 23:49, Simone Bordet wrote: > > I don't see why the message should be reassembled, given > MessagePart.[FIRST|PART|LAST] ? > It's not that the user can ask for the kind of MessagePart, e.g. ask > only for WHOLE messages that the implementation must

  1   2   3   >