On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons wrote:
>> With the advent of JEP 467, `///` comments may be treated as documentation
>> comments, and may be subject to the recently new `javac` warning about
>> "dangling doc comments" in unexpected places.
>>
>> In keeping with the policy
On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons wrote:
>> With the advent of JEP 467, `///` comments may be treated as documentation
>> comments, and may be subject to the recently new `javac` warning about
>> "dangling doc comments" in unexpected places.
>>
>> In keeping with the policy
On Tue, 28 May 2024 01:46:01 GMT, Bradford Wetmore wrote:
> It's too late now, but I might have suggested a short sleep between attempts.
@bradfordwetmore what would be the rationale for that? If the ReuseAddr::run
method throws BindException, then retrying immediately should hopefully let us
On Sun, 26 May 2024 08:22:44 GMT, Lei Zhu wrote:
> Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and
> MulticastSocket.send(DatagramPacket, byte)
@Korov as @AlanBateman has indicated this PR is premature. These methods have
just been marked deprecated for removal by
On Tue, 21 May 2024 07:26:17 GMT, Alan Bateman wrote:
>> This is the implementation changes for JEP 471.
>>
>> The methods in sun.misc.Unsafe for on-heap and off-heap access are
>> deprecated for removal. This means a removal warning at compile time. No
>> methods have been removed. A
On Thu, 23 May 2024 08:42:00 GMT, Daniel Fuchs wrote:
> This is one of these tests that is not really fixable if any other process
> that might open a socket runs concurrently with it on the same machine:
> nothing can guarantee that if you open a socket, close it, then open a new
ee. It might work most of
> the time, but success can’t be guaranteed.
>
> The only thing we can do in order to attempt to minimize noisy intermittent
> failures is retry the whole test if a BindException is thrown.
Daniel Fuchs has updated the pull request incrementally with one
This is one of these tests that is not really fixable if any other process that
might open a socket runs concurrently with it on the same machine: nothing can
guarantee that if you open a socket, close it, then open a new socket on the
same port, that port will still be free. It might work most
On Fri, 17 May 2024 11:33:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which clarifies the value
>> type for the `java.net.SocketOptions.SO_LINGER` option?
>
> Jaikiran Pai has updated the pull request incrementally with one additional
> commit since the
On Mon, 20 May 2024 06:02:31 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Sun, 19 May 2024 19:05:19 GMT, Nizar Benalla wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/package-info.java
>> line 26:
>>
>>> 24: */
>>> 25:
>>> 26: /**
>>
>> I assume you'll need to prepend each line with `*` too, which has the side
>> effect of making
On Fri, 17 May 2024 11:23:34 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Fri, 17 May 2024 11:50:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to deprecate for
>> removal 3 methods on `java.net.MulticastSocket`? This addresses
>> https://bugs.openjdk.org/browse/JDK-8332181.
>>
>> As noted in that issue these methods have
On Fri, 17 May 2024 11:47:34 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/net/NetMulticastSocket.java line 655:
>>
>>> 653: @Deprecated
>>> 654: @Override
>>> 655: @SuppressWarnings("removal")
>>
>> Instead of adding `@SuppressWarning("removal")` here (and at other
On Wed, 15 May 2024 04:20:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to deprecate for
> removal 3 methods on `java.net.MulticastSocket`? This addresses
> https://bugs.openjdk.org/browse/JDK-8332181.
>
> As noted in that issue these methods have been
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 20:17:18 GMT, Kevin Walls wrote:
>> Running JConsole from a previous JDK, and attaching to jdk-23 (after
>> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
>> Management Extension (JMX) Subject Delegation feature), the MBean tab is
>> blank.
>>
On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls wrote:
>> This shows that when SubjectDelegation was not used, a null-filled array of
>> the same length as the two other arrays was expected before (in previous
>> versions of the JDK where SubjectDelegation was supported, but in the case
>>
On Thu, 16 May 2024 10:37:36 GMT, Kevin Walls wrote:
>> This shows that when SubjectDelegation was not used, a null-filled array of
>> the same length as the two other arrays was expected before (in previous
>> versions of the JDK where SubjectDelegation was supported, but in the case
>>
On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls wrote:
>> Well my thinking was this: the fact that the jconsole tab was blank shows
>> that the array may being passed. The previous code verified that all three
>> arrays had the same length - so it would have failed if the array had a
>> length
On Thu, 16 May 2024 10:16:58 GMT, Kevin Walls wrote:
>> Well my thinking was this: the fact that the jconsole tab was blank shows
>> that the array may being passed. The previous code verified that all three
>> arrays had the same length - so it would have failed if the array had a
>> length
On Tue, 7 May 2024 10:08:12 GMT, Aleksei Efimov wrote:
>> The parsing code and the test changes look good to me with a couple of minor
>> suggestions.
>
>> @AlekseiEfimov @jaikiran @Michael-Mc-Mahon Could you please take a look and
>> review the [CSR
On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 984:
>>
>>> 982: }
>>> 983: if (names.length != filters.length) {
>>> 984: final String msg = "The lengths of
On Wed, 15 May 2024 20:02:26 GMT, Kevin Walls wrote:
>> src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
>> line 984:
>>
>>> 982: }
>>> 983: if (names.length != filters.length) {
>>> 984: final String msg = "The lengths of
On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls wrote:
> Running JConsole from a previous JDK, and attaching to jdk-23 (after
> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
> Management Extension (JMX) Subject Delegation feature), the MBean tab is
> blank.
>
> In
On Wed, 15 May 2024 16:59:59 GMT, Kevin Walls wrote:
> Running JConsole from a previous JDK, and attaching to jdk-23 (after
> [JDK-832](https://bugs.openjdk.org/browse/JDK-832): Remove the Java
> Management Extension (JMX) Subject Delegation feature), the MBean tab is
> blank.
>
> In
On Mon, 6 May 2024 18:36:24 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Wed, 15 May 2024 08:21:36 GMT, Christoph Langer wrote:
>> Christoph Langer 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 contains 11 additional
>>
On Tue, 7 May 2024 08:43:09 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Mon, 13 May 2024 23:59:17 GMT, Viktor Klang wrote:
>> This change adds wrapping of the CancellationException produced by
>> CompletableFuture::get() and CompletableFuture::join() to add more
>> diagnostic information and align better with FutureTask.
>>
>> Running the sample code from the
Hi,
With HTTP/3 having reached the state of Proposed Standard,
we propose to update the HttpClient provided by the java.net.http
module [1] to additionally support the HTTP/3 protocol.
HTTP/3 is an evolution of HTTP/2 based on the Quic transport,
which uses components from TLSv1.3 to be secure
On Mon, 13 May 2024 17:12:33 GMT, Raffaello Giulietti
wrote:
>> Not sure if that's an issue - but if you wanted/needed to delay the loading
>> of those random generator classes that will not be used until something
>> actually wants to use them, you could consider using a `Supplier> extends
On Mon, 13 May 2024 13:21:23 GMT, Raffaello Giulietti
wrote:
>> A followup PR is fine. I think once this PR which addresses the API aspects
>> (like removal of ServiceLoader and then updates to the create() method
>> javadoc) is integrated, then the subsequent PR can just be all internal
>>
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Mon, 13 May 2024 11:47:38 GMT, Maurizio Cimadamore
wrote:
>> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
>> the use of JNI in the following ways:
>>
>> * `System::load` and `System::loadLibrary` are now restricted methods
>> * `Runtime::load` and
On Fri, 10 May 2024 14:46:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8332020?
>>
>> `jwebserver` when it is launched prints a URL where the server is
>> accessible. When launched using an IPv6 bind
On Fri, 10 May 2024 13:58:58 GMT, Nizar Benalla wrote:
>> Passes Tier 1-3
>> Please review this change that aims to fix a bug when parsing the client's
>> request.
>>
>> RFC 9110 states
>>
>>> 11. HTTP Authentication 11.1. Authentication Scheme
>> HTTP provides a general framework for access
ull request incrementally with one additional
> commit since the last revision:
>
> Use -p 0 in the test
>
> Co-authored-by: Daniel Fuchs <67001856+df...@users.noreply.github.com>
LGTM
-
Marked as reviewed by dfuchs (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19173#pullrequestreview-2050100758
On Fri, 10 May 2024 10:31:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8332020?
>>
>> `jwebserver` when it is launched prints a URL where the server is
>> accessible. When launched using an IPv6 bind
On Fri, 10 May 2024 10:05:07 GMT, Jaikiran Pai wrote:
>> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java
>> line 185:
>>
>>> 183:
>>> writer.println(ResourceBundleHelper.getMessage("msg.start.anylocal", root,
>>> port, url));
>>>
On Fri, 10 May 2024 01:22:17 GMT, SendaoYan wrote:
>> Hi,
>> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
>> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
>> the java code, but the timeout value is set to 5 second.
>>
>> I think it has
On Fri, 10 May 2024 09:21:15 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address
> https://bugs.openjdk.org/browse/JDK-8332020?
>
> `jwebserver` when it is launched prints a URL where the server is accessible.
> When launched using an IPv6 bind
On Thu, 9 May 2024 12:49:09 GMT, Nizar Benalla wrote:
>> Passes Tier 1-3
>> Please review this change that aims to fix a bug when parsing the client's
>> request.
>>
>> RFC 9110 states
>>
>>> 11. HTTP Authentication 11.1. Authentication Scheme
>> HTTP provides a general framework for access
On Fri, 10 May 2024 03:53:12 GMT, Nizar Benalla wrote:
>> Please review this simple change, aiming to fix current uses of `@since` in
>> the source code
>> -The constructor
>> BasicAuthenticator(java.lang.String,java.nio.charset.Charset) needs an
>> `@since 14` instead of 9.
>>
On Thu, 9 May 2024 11:19:14 GMT, Erik Gahlin wrote:
>> Hi,
>>
>> Could I have a review of a change that moves the jdk.FileRead and
>> jdk.FileWrite events to java.base to remove the use of the ASM
>> instrumentation.
>>
>> Testing: jdk/jdk/jfr
>>
>> Thanks
>> Erik
>
> Erik Gahlin has
On Wed, 8 May 2024 04:23:47 GMT, Nizar Benalla wrote:
> Passes Tier 1-3
> Please review this change that aims to fix a bug when parsing the client's
> request.
>
> RFC 9110 states
>
>> 11. HTTP Authentication 11.1. Authentication Scheme
> HTTP provides a general framework for access control
On Thu, 18 Apr 2024 13:29:21 GMT, Michael McMahon wrote:
>>> which lists the methods that parse as decimal only, and the new method
>>> which parses using the "loose" syntax.
>>
>> That might not be practical: the only method that supports non decimal form
>> is the new `ofBSDLiteral`. But
On Tue, 30 Apr 2024 11:23:01 GMT, Christian Stein wrote:
> Please pre-review this draft pull request adding a default for response for
> the `/favicon.ico` path to the Simple Web Server introduced by [JEP
> 408](https://openjdk.org/jeps/408). The image in this PR is a copy of
>
On Tue, 7 May 2024 08:43:09 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Mon, 6 May 2024 05:36:10 GMT, Jaikiran Pai wrote:
>> Can I get a review of this test-only fix which addresses the intermittent
>> failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
>> Windows?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8331334, the test
On Thu, 25 Apr 2024 17:01:52 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update copyright date
Tests were green. Please
On Mon, 6 May 2024 05:36:10 GMT, Jaikiran Pai wrote:
>> Can I get a review of this test-only fix which addresses the intermittent
>> failrues in `com/sun/net/httpserver/HttpsParametersClientAuthTest.java` on
>> Windows?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8331334, the test
On Fri, 26 Apr 2024 13:24:08 GMT, Michael McMahon wrote:
>>> I created a PR for the related proposed api changes #18955
>>
>> I don't think I have the ability to create issues, so I can't create one for
>> the api changes.
>
>> > I created a PR for the related proposed api changes #18955
>>
On Thu, 2 May 2024 04:29:26 GMT, Jaikiran Pai wrote:
> Can I please get a review of this copyright text only change which removes
> the "Classpath" exception from the
> `test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java` test file and
> thus addresses
On Thu, 2 May 2024 04:26:25 GMT, Jaikiran Pai wrote:
> Can I please get a review of this copyright text only change that removes the
> "Classpath" exception from these test files and thus addresses
> https://bugs.openjdk.org/browse/JDK-8331513?
LGTM.
-
Marked as reviewed by
On Wed, 1 May 2024 13:26:39 GMT, robert engels wrote:
> I might prefer `OS beginChunkedResponse()` and `OS beginFixedResponse()`.
That's not a bad suggestion (whether startXxxx or beginXxxx). My gripe with `OS
sendResponseHeadersX` is that the existing `void sendResponseHeaders`
returns
On Wed, 1 May 2024 12:40:52 GMT, robert engels wrote:
> OutputStream sendResponseHeadersChunked(int code);
> OutputStream sendResponseHeadersFixed(int code,long length);
I still think that these methods should either return `void` or be renamed,
though I have been struggling to find a name
On Tue, 30 Apr 2024 15:55:05 GMT, robert engels wrote:
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>> line 237:
>>
>>> 235: */
>>> 236: public final OutputStream sendResponseHeadersChunked(int code)
>>> throws IOException {
>>> 237:
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
>
On Fri, 26 Apr 2024 14:54:30 GMT, Michael McMahon wrote:
>> robert engels has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update
>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java
>>
>> Co-authored-by:
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
>
On Sat, 27 Apr 2024 13:15:37 GMT, Christoph Langer wrote:
>> While working in that area I found some potential for cleanup of a few tests.
>>
>> Most notably:
>>
>> B5045306.java:
>> - does not need to run in othervm
>> - the executor service that it uses should be shut down eventually to free
On Thu, 25 Apr 2024 08:04:16 GMT, Christoph Langer wrote:
>> test/jdk/sun/net/www/http/KeepAliveCache/B5045306.java line 154:
>>
>>> 152:
>>> 153: // if Keep-Alive-SocketCleaner consumes more than
>>> 50% of cpu then we
>>> 154: // can assume a
On Thu, 25 Apr 2024 15:24:12 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add https testing
On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeliński wrote:
> This patch fixes leak reporting in `ForbiddenHeadTest.java` and
> `ProxySelectorTest.java`.
>
> The tests were checking for leaks, but the detected problems were not
> reported to the test harness. Additionally,
On Mon, 22 Apr 2024 15:23:01 GMT, robert engels wrote:
>> Just to be clear - I agree with Daniel that the line 851 should be removed.
>> I was just speculating about the possible backward compatibility issues of
>> *not* flushing the stream after writing the headers. We saw some test
>>
On Mon, 22 Apr 2024 14:40:02 GMT, robert engels wrote:
>> I can see that a bad handler could call `sendResponse(500, 0);` instead of
>> `sendResponse(500, -1)`, and forget to close the body output stream or the
>> exchange. A client might just not read the body if it receives 500. Before
>>
On Mon, 22 Apr 2024 13:05:31 GMT, robert engels wrote:
>> also, I reviewed the semantics of the buffered output stream. It is fully
>> synchronized, so flushing here is fine and cannot corrupt the data to the
>> client. But still, I don't think it is needed as it doesn't really solve
>>
On Fri, 19 Apr 2024 18:49:33 GMT, robert engels wrote:
>> src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java
>> line 142:
>>
>>> 140: try {
>>> 141: /* write any pending chunk data */
>>> 142: writeChunk();
>>
>> Isn't there a risk
On Fri, 19 Apr 2024 18:43:18 GMT, robert engels wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fix chunked response for small packets
On Fri, 19 Apr 2024 14:39:08 GMT, robert engels wrote:
>> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 45:
>>
>>> 43: import java.util.logging.*;
>>> 44:
>>> 45: public class B6968351 {
>>
>> You could use a more revealing name here; the B*bug numer* aren't very useful
>
> This was
On Fri, 19 Apr 2024 14:37:27 GMT, robert engels wrote:
>> Before doing that, you might want to check the HTTPS case. As far as I can
>> tell, we don't do any buffering when SSL is in use.
>
> I think it was safer for future enhancements the way it was done. The other
> advantage of using a
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Fri, 19 Apr 2024 09:03:36 GMT, Daniel Fuchs wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line
> 210:
>
>> 208: this.rcode = rCode;
>> 209:
On Fri, 19 Apr 2024 08:53:13 GMT, Daniel Jeliński wrote:
>> fix bug JDK-B6968351 by avoiding flush after response headers
>
> test/jdk/com/sun/net/httpserver/bugs/B6968351.java line 75:
>
>> 73: long time = System.currentTimeMillis()-start;
>> 74: System.out.println("time
On Sat, 6 Apr 2024 23:35:48 GMT, robert engels wrote:
> fix bug JDK-B6968351 by avoiding flush after response headers
Hi Robert, thanks for working on this issue.
src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 210:
> 208: this.rcode = rCode;
> 209:
On Thu, 18 Apr 2024 13:29:21 GMT, Michael McMahon wrote:
> I think we only need to talk about the methods in InetAddress. Though it
> could be phrased as `ofPosixLiteral` supports decimal, hex and octal. All
> other parsing is decimal only.
Yes. that latter formulation might be better.
On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing wrote:
>> Currently the JFR event FileForceEvent is generated by instrumenting the
>> sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer
>> mirror events with static methods.
>>
>> Added the event at
On Thu, 18 Apr 2024 13:47:04 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix the issue
> reported in https://bugs.openjdk.org/browse/JDK-8330572?
>
> As noted in that issue, the internal method `checkOpen()` should only be
> called when picking a
On Thu, 18 Apr 2024 12:40:27 GMT, Christoph Langer wrote:
>> The test case sun/net/www/http/HttpClient/KeepAliveTest.java could be more
>> effective.
>>
>> It tests a matrix of HTTP client settings and server behavior, resulting in
>> 160 individual test scenarios. Each is tested in an own
On Thu, 18 Apr 2024 10:24:30 GMT, Michael McMahon wrote:
> which lists the methods that parse as decimal only, and the new method which
> parses using the "loose" syntax.
That might not be practical: the only method that supports non decimal form is
the new `ofBSDLiteral`. But any other
addresses
>> in "loose" syntax, compatible with `inet_addr` POSIX api. The implementation
>> is based on `.isBsdParsableV4()` method added along with JDK-8277608 [4].
>> The changes in the original algorithm are as follows:
>>
>> - `IPAddressUtil#parseB...
On Wed, 17 Apr 2024 14:26:35 GMT, Jaikiran Pai wrote:
> The changes proposed in this PR introduce a new paragraph in the class level
> documentation just before the line which states the dotted-quad string. So I
> think it may not be clear enough whether dotted-quad string implies decimal
>
On Wed, 17 Apr 2024 14:02:05 GMT, Jaikiran Pai wrote:
> Should we be setting any expectations by specifying what
> InetAddress.getHostAddress() will return for an Inet4Address constructed
> using this new Inet4Address.ofPosixLiteral() method? In its current form I
> believe it will continue
On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai wrote:
> This brings in the CPU24_04 changes.
This looks reasonable. I haven't been involved in all the fixes here - but I
haven't spotted anything obviously wrong. The changes to the ConnectionPool
look right. If some of the fixes had conflicts
On Wed, 17 Apr 2024 01:09:30 GMT, Jaikiran Pai wrote:
> This brings in the CPU24_04 changes.
This looks reasonable. I haven't been involved in all the fixes here - but I
haven't spotted anything obviously wrong. The changes to the ConnectionPool
look right. If some of the fixes had conflicts
On Mon, 15 Apr 2024 20:41:10 GMT, Tim Prinzing wrote:
>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:
>>
>>> 48:
>>> 49: public static void main(String[] args) throws Throwable {
>>> 50: File blah = File.createTempFile("blah", null);
>>
>> Can you
On Thu, 11 Apr 2024 16:08:31 GMT, Alan Bateman wrote:
>> We should probably find a way to not emit the event if n == 0 and the
>> operation was interrupted by `Selector.wakeUp`. Since we have another issue
>> logged to emit a spin event, I wonder if we should only commit the event
>> here if
On Thu, 11 Apr 2024 12:58:07 GMT, Sergey Chernyshev
wrote:
>> There are two distinct approaches to parsing IPv4 literal addresses. One is
>> the Java baseline "strict" syntax (all-decimal d.d.d.d form family), another
>> one is the "loose" syntax of RFC 6943 section 3.1.1 [1] (POSIX
On Wed, 10 Apr 2024 15:30:52 GMT, Sergey Chernyshev
wrote:
>> src/java.base/share/classes/java/net/Inet4Address.java line 103:
>>
>>> 101: * octal and hexadecimal address segments. Please refer to
>>> 102: * https://www.ietf.org/rfc/rfc6943.html#section-3.1.1;>
>>> RFC
>>> 103: * 6943:
1 - 100 of 5594 matches
Mail list logo
