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***` tes
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, s
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 or
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 one
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 explains
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 o
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 in
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 one
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 one
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 +
>> codeLengthOf
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)
>>
&
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 c
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 javado
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: https://git.open
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
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
> src/java.net.http
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 c
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
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 t
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 to
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
th
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
>>
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
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
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 spa
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
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;
>> 12
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).
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
> 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/
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
> 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
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
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&pr=5475&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8273616
Stats
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
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 shou
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
collections](https://github.com/cbeust/t
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
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
> 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
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: https://git.openjdk.java.net/jdk/pull/11
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
>> java.net](https://bugs.openjdk.java.net/browse/
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 seq
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: sc
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> str
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 ma
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
> http://cr.openjdk.java.net/~ryadav/webrev_8
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
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 a
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:
>
> http://cr.openjdk.ja
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
Here's 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 ty
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,
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:
>>>
prone 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.open
t.
-Pavel
> 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, whi
sim/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 s
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 kno
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, in
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 chan
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 was
is was causing 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 impor
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
java
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"
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
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 wrote
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
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 fr
> 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 comp
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
> 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 with
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 gener
ow 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 chan
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.
> 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.
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 completionCF.com
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: https://bugs.openjdk.java.net/brows
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 bug
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.
I
I've applied your patch and run through our test system. The
sun/net/www/protocol/http/B6890349.java
test failed just like you said. I'm happy to say that it was the only test in
the whole networking area that failed. So test-wise it looks good.
-Pavel
> 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
>> clea
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) t
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 appl
Looks good to me.
-Pavel
> 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
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 feedback.
> 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 n
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 changed
> 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 c.s
> 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 port
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 du
> 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
> brin
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
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 3.10
> 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?
http://cr.openjdk.java.net/~prap
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
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 test
> 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 H
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 v
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 APIs.
>
> I second that. T
1 - 100 of 236 matches
Mail list logo
