On Wed, 15 Jun 2022 18:17:39 GMT, Andrey Turbanov wrote:
>> https://github.com/openjdk/jdk/blob/900d967da52afca9b239d8a58aa81b48b9fe0a78/src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java#L191-L196
>>
>> Method `Http2ClientImpl.deleteConnection` removes `Http2Connection`
On Fri, 17 Jun 2022 09:17:53 GMT, KIRIYAMA Takuya wrote:
>> src/java.base/share/classes/java/net/URI.java line 2140:
>>
>>> 2138: } else {
>>> 2139: sb.append("/");
>>> 2140: }
>>
>> This is wrong as it will cause
>> `URI.create("foo").resolve(URI.creat
Hi,
Please find here a patch that should help the HttpClient's SelectorManager
thread to terminate more timely, allowing the resources consumed by the client
to be released earlier.
The idea is to use a Cleaner registered with the HttpClientFacade to wakeup the
Selector when the facade is bein
On Mon, 20 Jun 2022 18:28:36 GMT, Сергей Цыпанов wrote:
> Shouldn't we use `Reference.refersTo()` instead of `Reference.get() == smth`
> in lines 428 and 501?
Hi Sergey, we could, and I'll do it for consistency.
Though in those two cases it doesn't really matter since the facade referent is
no
On Fri, 20 May 2022 08:25:02 GMT, Сергей Цыпанов wrote:
>> - use `String.equalsIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - use `String.compareToIgnoreCase()` instead of hand-written code relying on
>> `String.charAt()`
>> - drop branches that are never execut
On Tue, 21 Jun 2022 17:31:59 GMT, Brent Christian wrote:
>> Hi,
>>
>> Please find here a patch that should help the HttpClient's SelectorManager
>> thread to terminate more timely, allowing the resources consumed by the
>> client to be released earlier.
>>
>> The idea is to use a Cleaner regi
On Wed, 22 Jun 2022 07:44:34 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which adds a utility to the JDK
>> test library to help launch the JWebServer? As noted in the JBS issue, this
>> utility does the necessary work to make sure when the `launch()` method
>> return
On Fri, 24 Jun 2022 08:49:06 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which fixes the broken link in the
> javadoc of `SimpleFileServer`? This fixes
> https://bugs.openjdk.org/browse/JDK-8288983 which has the necessary context
> on why/when this link broke.
>
> I u
On Fri, 24 Jun 2022 14:31:59 GMT, Bill Huang wrote:
> Failure was observed on
> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
> received unexpectedly (
> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
> could be caused by interference from
On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a patch that should help the HttpClient's SelectorManager
> thread to terminate more timely, allowing the resources consumed by the
> client to be released earlier.
>
> The idea is t
On Sun, 26 Jun 2022 06:08:07 GMT, Jaikiran Pai wrote:
>> Hi,
>>
>> Please find here a patch that should help the HttpClient's SelectorManager
>> thread to terminate more timely, allowing the resources consumed by the
>> client to be released earlier.
>>
>> The idea is to use a Cleaner registe
On Mon, 20 Jun 2022 14:09:27 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a patch that should help the HttpClient's SelectorManager
> thread to terminate more timely, allowing the resources consumed by the
> client to be released earlier.
>
> The idea is t
On Tue, 28 Jun 2022 18:44:38 GMT, Andrey Turbanov wrote:
> Http2ClientImpl.stopping and Http2ClientImpl.failures are always accessed
> under synchronized(this).
> So we can remove 'volatile' modifier from 'stopping'. And remove
> 'synchronizedSet' wrapper from 'failures'
src/java.net.http/shar
On Tue, 28 Jun 2022 17:19:32 GMT, Bill Huang wrote:
>> Failure was observed on
>> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
>> received unexpectedly (
>> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
>> could be caused by interference
On Wed, 29 Jun 2022 12:05:42 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses
>> https://bugs.openjdk.org/browse/JDK-8289291?
>>
>> As noted in that issue, right now, the Http(s)Server sets an incorrect value
>> for the `max` parameter of the `Keep-Alive` h
On Wed, 29 Jun 2022 20:57:14 GMT, Andrey Turbanov wrote:
>> Http2ClientImpl.stopping and Http2ClientImpl.failures are always accessed
>> under synchronized(this).
>> So we can remove 'volatile' modifier from 'stopping'. And remove
>> 'synchronizedSet' wrapper from 'failures'
>
> Andrey Turbanov
On Thu, 30 Jun 2022 14:26:23 GMT, Ryan Ernst wrote:
>> Since ReplyingServer binds to an open port on the system where tests
>> run, it is possible some other program probes that port while the test
>> is running. If the probe request does not have request params, the
>> request is invalid and a t
On Fri, 1 Jul 2022 17:55:54 GMT, Ryan Ernst wrote:
>> Since ReplyingServer binds to an open port on the system where tests
>> run, it is possible some other program probes that port while the test
>> is running. If the probe request does not have request params, the
>> request is invalid and a te
On Mon, 27 Jun 2022 05:31:47 GMT, KIRIYAMA Takuya wrote:
>> src/java.base/share/classes/java/net/URL.java line 1101:
>>
>>> 1099: throw new MalformedURLException(e.getMessage());
>>> 1100: }
>>> 1101: return url;
>>
>> Please revert the changes in java.net.URL. It's
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
Please find enclosed a simple test fix.
This test has been observed failing once with an SSLException. My suspicion is
that some random process (other test or ...) has tried to connect to the test
ReplyingServer and sent some plain text that failed the handshake.
The fix hardens the server to cl
On Tue, 12 Jul 2022 07:44:39 GMT, Jaikiran Pai wrote:
>> Please find enclosed a simple test fix.
>> This test has been observed failing once with an SSLException. My suspicion
>> is that some random process (other test or ...) has tried to connect to the
>> test ReplyingServer and sent some pla
he fix hardens the server to close the connection and proceed to accept the
> next one, for a limited number of times...
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
increase maxUnexpected limit
-
Ch
On Tue, 12 Jul 2022 08:07:36 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/ResponseBodyBeforeError.java line 349:
>>
>>> 347: @Override
>>> 348: public void run() {
>>> 349: int maxUnexpected = 2;
>>
>> H
On Mon, 11 Jul 2022 14:35:55 GMT, Daniel Fuchs wrote:
> Please find enclosed a simple test fix.
> This test has been observed failing once with an SSLException. My suspicion
> is that some random process (other test or ...) has tried to connect to the
> test ReplyingServer and sen
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Changes to HttpURLConnection look good to me
On Mon, 1 Aug 2022 11:01:01 GMT, Daniel Jeliński wrote:
> This patch fixes a race condition in KeepAliveProperty test. The client
> thread could read the `pass` field and fail the test before the server thread
> had a chance to set the field value to `true`. The fix adds an explicit wait
> for
On Wed, 3 Aug 2022 14:30:08 GMT, Daniel Jeliński wrote:
>> This patch fixes a race condition in KeepAliveProperty test. The client
>> thread could read the `pass` field and fail the test before the server
>> thread had a chance to set the field value to `true`. The fix adds an
>> explicit wait
On Fri, 5 Aug 2022 09:04:19 GMT, Michael McMahon wrote:
>> test/jdk/sun/net/www/http/KeepAliveCache/B8291637.java line 27:
>>
>>> 25: * @test
>>> 26: * @bug 8291637
>>> 27: * @run main/othervm -Dhttp.keepAlive.time.server=20 -esa -ea B8291637
>>
>> Is it intentional that we are setting the -
On Fri, 5 Aug 2022 10:32:56 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Some new keep alive tests are exposing some old bugs. In this case if the
>> server sends an invalid timeout (say -20 seconds) we accept it creating a
>> timeout in the past. So, the first time the keep alive thread wakes up
On Wed, 20 Jul 2022 14:02:39 GMT, thyecust wrote:
> The condition at line 57 (after while) will evaluate to false
> if startLine == null, so the previous if-condition is covered.
LGTM. Could you update the Copyright year in the file and also run tier2 tests
before integrating?
-
P
On Fri, 5 Aug 2022 13:36:47 GMT, thyecust wrote:
>> The condition at line 57 (after while) will evaluate to false
>> if startLine == null, so the previous if-condition is covered.
>
> thyecust has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webre
On Fri, 5 Aug 2022 15:07:17 GMT, thyecust wrote:
>> The condition at line 57 (after while) will evaluate to false
>> if startLine == null, so the previous if-condition is covered.
>
> thyecust has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webre
On Fri, 5 Aug 2022 16:46:06 GMT, Roger Riggs wrote:
>> thyecust 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 six additional commits
>> since
On Fri, 5 Aug 2022 17:21:28 GMT, Daniel Fuchs wrote:
>> src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java line 54:
>>
>>> 52: startLine = readLine();
>>> 53: /* skip blank lines */
>>> 54: } while
On Fri, 5 Aug 2022 23:02:15 GMT, thyecust wrote:
>> The condition at line 57 (after while) will evaluate to false
>> if startLine == null, so the previous if-condition is covered.
>
> thyecust has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Tue, 9 Aug 2022 11:02:31 GMT, KIRIYAMA Takuya wrote:
>> Consider an authority component without trailing "/" as a base URI. When
>> resolving a relative path against this base URI, the resulting URI is a
>> concatenated URI without "/".
>> This behaviour should be fixed, which is rationalize
On Thu, 28 Jul 2022 06:48:56 GMT, KIRIYAMA Takuya wrote:
> The current documentation of URI class describes relationship between resolve
> and relativize methods as follows.
>
>
> For any two normalized URIs u and v,
> u.relativize(u.resolve(v)).equals(v) and
> u.resolve(u.relativize(v
On Mon, 30 May 2022 06:05:56 GMT, KIRIYAMA Takuya wrote:
>> @tkiriyama You're using the wrong bugid.
>> [JDK-8272707](https://bugs.openjdk.java.net/browse/JDK-8272707) has nothing
>> to do with URI. Please use the correct bugid.
>
>> You're using the wrong bugid.
>> [JDK-8272707](https://bugs.
Please find here a change that improves SpecialHeadersTest. This test creates a
large amount of ephemeral clients and has been observed running out of heap
space in our CI once. This change updates the test to wait for the previous
HttpClient to be eligible for garbage collection before it creat
On Thu, 18 Aug 2022 06:52:41 GMT, Jaikiran Pai wrote:
>> Please find here a change that improves SpecialHeadersTest. This test
>> creates a large amount of ephemeral clients and has been observed running
>> out of heap space in our CI once. This change updates the test to wait for
>> the previ
On Thu, 18 Aug 2022 06:41:49 GMT, Jaikiran Pai wrote:
>> Please find here a change that improves SpecialHeadersTest. This test
>> creates a large amount of ephemeral clients and has been observed running
>> out of heap space in our CI once. This change updates the test to wait for
>> the previ
On Thu, 18 Aug 2022 07:31:22 GMT, Jaikiran Pai wrote:
> Additionally, the `SpecialHeadersTest` would need a copyright year update and
> given the kind of changes we are doing in this PR, would it even warrant a
> `@bug` id inclusion?
This is a test bug. We only add a `@bug` for test changes th
On Thu, 18 Aug 2022 10:01:28 GMT, Michael McMahon wrote:
> I don't really understand why the test (originally) needed to create so many
> clients. Wouldn't it be easier and more maintainable to only create the
> minimum number of clients?
Yeah - maybe. But there are differences between a brand
ction before it creates a new one.
> It also verifies that no outstanding operation are still running on the
> client by the time the client is released.
Daniel Fuchs has updated the pull request incrementally with one additional
commit since the last revision:
Integrat
On Wed, 17 Aug 2022 17:06:12 GMT, Daniel Fuchs wrote:
> Please find here a change that improves SpecialHeadersTest. This test creates
> a large amount of ephemeral clients and has been observed running out of heap
> space in our CI once. This change updates the test to wait for the
On Wed, 17 Aug 2022 17:06:12 GMT, Daniel Fuchs wrote:
> Please find here a change that improves SpecialHeadersTest. This test creates
> a large amount of ephemeral clients and has been observed running out of heap
> space in our CI once. This change updates the test to wait for the
On Mon, 22 Aug 2022 08:26:19 GMT, Ramesh Bhagavatam Gangadhar
wrote:
> There are total 160 scenarios written with combination of client properties
> (Client Scenarios) and Server Response (Server Scenarios).
>
> In tabular format, Client and Server scenarios along with expected output are
> d
On Mon, 22 Aug 2022 08:26:19 GMT, Ramesh Bhagavatam Gangadhar
wrote:
> There are total 160 scenarios written with combination of client properties
> (Client Scenarios) and Server Response (Server Scenarios).
>
> In tabular format, Client and Server scenarios along with expected output are
> d
On Mon, 22 Aug 2022 08:26:19 GMT, Ramesh Bhagavatam Gangadhar
wrote:
> There are total 160 scenarios written with combination of client properties
> (Client Scenarios) and Server Response (Server Scenarios).
>
> In tabular format, Client and Server scenarios along with expected output are
> d
On Mon, 22 Aug 2022 17:18:21 GMT, Ramesh Bhagavatam Gangadhar
wrote:
>> There are total 160 scenarios written with combination of client properties
>> (Client Scenarios) and Server Response (Server Scenarios).
>>
>> In tabular format, Client and Server scenarios along with expected output
>>
On Tue, 23 Aug 2022 05:31:31 GMT, Ramesh Bhagavatam Gangadhar
wrote:
>> There are total 160 scenarios written with combination of client properties
>> (Client Scenarios) and Server Response (Server Scenarios).
>>
>> In tabular format, Client and Server scenarios along with expected output
>>
On Fri, 26 Aug 2022 07:51:16 GMT, Jaikiran Pai wrote:
> Can I please get a review of this javadoc only change for
> `DatagramPacket#setLength()` method? This addresses
> https://bugs.openjdk.org/browse/JDK-7113208.
>
> I haven't create a CSR because the javadoc was already stating the correct
On Fri, 26 Aug 2022 09:55:11 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this javadoc only change for
>> `DatagramPacket#setLength()` method? This addresses
>> https://bugs.openjdk.org/browse/JDK-7113208.
>>
>> I haven't create a CSR because the javadoc was already stating the cor
On Fri, 26 Aug 2022 09:22:26 GMT, Jaikiran Pai wrote:
> Can I please get a review of this javadoc only change which addresses
> https://bugs.openjdk.org/browse/JDK-8292968?
>
> The updated javadoc now uses the `@systemProperty`, since this is the place
> where the semantics of this system prop
On Fri, 26 Aug 2022 09:22:26 GMT, Jaikiran Pai wrote:
> Can I please get a review of this javadoc only change which addresses
> https://bugs.openjdk.org/browse/JDK-8292968?
>
> The updated javadoc now uses the `@systemProperty`, since this is the place
> where the semantics of this system prop
On Thu, 1 Sep 2022 07:01:14 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this javadoc only change for
>> `DatagramPacket#setLength()` method? This addresses
>> https://bugs.openjdk.org/browse/JDK-7113208.
>>
>> I haven't create a CSR because the javadoc was already stating the corr
On Mon, 5 Sep 2022 09:57:51 GMT, KIRIYAMA Takuya wrote:
>> Let me try to summarize: there are several things that we could do:
>>
>> 1. nothing: continue throwing IIOBE
>> 2. throw IAE instead of IIOBE, and let IAE trickle up the calling stack to
>> the callers code
>> 3. throw MUE instead o
On Mon, 5 Sep 2022 13:36:04 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix
> https://bugs.openjdk.org/browse/JDK-8292044?
>
> The linked JBS issue notes two parts to fixing this. Part one is to
> (internally) ignore the intermediate 1xx informational
On Wed, 7 Sep 2022 06:36:33 GMT, Jaikiran Pai wrote:
>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an
>> idle Http2 Connection before a server sends a GOAWAY frame. For example, a
>> server or cloud based tool could close a TCP connection silently whe
On Fri, 9 Sep 2022 08:17:52 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8292044?
>>
>> The linked JBS issue notes two parts to fixing this. Part one is to
>> (internally) ignore the intermediate 1xx informati
On Fri, 9 Sep 2022 09:57:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8292044?
>>
>> The linked JBS issue notes two parts to fixing this. Part one is to
>> (internally) ignore the intermediate 1xx informati
On Fri, 9 Sep 2022 11:21:51 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix
> https://bugs.openjdk.org/browse/JDK-8170305?
>
> The commit in this PR changes the internal implementation of
> `HttpURLConnection` to ignore interim informational 1xx respon
On Fri, 9 Sep 2022 13:08:21 GMT, Julian Reschke wrote:
> A 101 response implies that the wire protocol is switching to the protocol
> specified in the "Upgrade" header field. I don't think it would be wise to
> ignore that, unless the protocol actually stays the same.
>
> Note that this is ind
On Mon, 12 Sep 2022 09:41:09 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8170305?
>>
>> The commit in this PR changes the internal implementation of
>> `HttpURLConnection` to ignore interim informational 1xx
On Mon, 12 Sep 2022 12:55:12 GMT, Jaikiran Pai wrote:
>> test/jdk/java/net/HttpURLConnection/Response1xxTest.java line 225:
>>
>>> 223: final HttpURLConnection urlConnection = (HttpURLConnection)
>>> requestURI.toURL().openConnection();
>>> 224: // we expect the request to fail
On Mon, 12 Sep 2022 13:26:45 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8170305?
>>
>> The commit in this PR changes the internal implementation of
>> `HttpURLConnection` to ignore interim informational 1xx
On Wed, 14 Sep 2022 13:57:34 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8292044?
>>
>> The linked JBS issue notes two parts to fixing this. Part one is to
>> (internally) ignore the intermediate 1xx informat
On Wed, 14 Sep 2022 13:59:13 GMT, Jaikiran Pai wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Close the connection/stream when a 101 response isn't expected
>
> src/java.net.http/share/classes/jdk/internal/net/htt
On Thu, 15 Sep 2022 07:25:04 GMT, Man Cao wrote:
> Hi all,
>
> Could anyone review this bug fix for ipv6-only system? See
> https://bugs.openjdk.org/browse/JDK-8293842 for detailed description of this
> bug.
>
> Ideally, the `socket(PF_INET6, ...)` or `socket(PF_INET, ...)` call should
> dep
On Tue, 20 Sep 2022 05:38:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix
>> https://bugs.openjdk.org/browse/JDK-8292044?
>>
>> The linked JBS issue notes two parts to fixing this. Part one is to
>> (internally) ignore the intermediate 1xx informat
Hi Anton,
There is a PR under review that will provide a system property
to control the maximum time an HTTP/2 connection can remain idle
before being closed by the client:
Please see https://git.openjdk.org/jdk/pull/10183
best regards,
-- daniel
On 21/09/2022 19:50, Anton Keks wrote:
Hello!
On Thu, 22 Sep 2022 10:53:52 GMT, tenor-dev wrote:
> IMHO, it would be great to use the same property as for HTTP/1 connections:
> jdk.httpclient.keepalive.timeout
> People are already expecting it to work with HTTP/2, but to everyone's
> surprise it doesn't.
>
> It would also be nice to suppor
On Fri, 23 Sep 2022 06:55:11 GMT, Daniel Jeliński wrote:
> Please review this patch that makes sure KeepAliveCache does not block all
> threads while closing sockets.
>
> Changes:
> - get operation no longer closes sockets; if there's no socket that is recent
> enough, get returns null and let
Hi Anton,
On 23/09/2022 10:02, Anton Keks wrote:
Do you have any background info, why the possibility wasn't there in the
beginning?
Probably this paragraph from the HTTP/2 spec:
HTTP/2 connections are persistent. For best performance, it is
expected that clients will not close connect
On Tue, 27 Sep 2022 09:18:18 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes sure KeepAliveCache does not block all
>> threads while closing sockets.
>>
>> Changes:
>> - get operation no longer closes sockets; if there's no socket that is
>> recent enough, get returns null a
On Tue, 27 Sep 2022 10:58:07 GMT, Michael McMahon wrote:
>> **Issue**
>> When using HTTP/2 with the HttpClient, it can often be necessary to close an
>> idle Http2 Connection before a server sends a GOAWAY frame. For example, a
>> server or cloud based tool could close a TCP connection silently
On Mon, 26 Sep 2022 15:35:28 GMT, Alan Bateman wrote:
> BlockingChannelOps.java and BlockingSocketOps.java test virtual threads doing
> blocking I/O on channels and java.net sockets.
>
> BlockingChannelOps has 32 tests at this time and takes nearly 120s to run due
> to several tests that sleep
On Tue, 27 Sep 2022 18:27:17 GMT, Daniel Jeliński wrote:
> Should I change that one as well?
No need. We'd have to evaluate whether that test wanted to test using
getLocalHost() first :-)
-
PR: https://git.openjdk.org/jdk/pull/10401
On Tue, 27 Sep 2022 19:00:28 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes sure KeepAliveCache does not block all
>> threads while closing sockets.
>>
>> Changes:
>> - get operation no longer closes sockets; if there's no socket that is
>> recent enough, get returns null a
On Fri, 16 Sep 2022 07:20:11 GMT, KIRIYAMA Takuya wrote:
>> I believe you are correct. Could you update the UriTest with some examples
>> and counter-examples to validate this claim?
>
> @dfuch
> Thank you for your review and suggestions.
>
>> A colon ':' may be more appropriate than a period
On Fri, 16 Sep 2022 06:15:01 GMT, KIRIYAMA Takuya wrote:
>> I fixed sun.net.www.ParseUtil.decode().
>>
>> ParseUtil.decode() always tries to decode after parsing '%', so if '%' is
>> located at the end of the String, IndexOutOfBoundsException is thrown. Also,
>> if '%' is shown after decodable
On Tue, 27 Sep 2022 23:12:43 GMT, Michael Ernst wrote:
> Feel free to break up the pull request if that is what is needed to free it
> from red tape.
Only you can do that @mernst
-
PR: https://git.openjdk.org/jdk/pull/10029
On Wed, 28 Sep 2022 14:45:54 GMT, Michael Ernst wrote:
>> Michael Ernst has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Reinstate typos in Apache code that is copied into the JDK
>> - Merge ../jdk-openjdk in
On Thu, 29 Sep 2022 08:13:27 GMT, Daniel Jeliński wrote:
>> Please review this patch that fixes the warning `JNI local refs ... exceeds
>> capacity` on Windows machines running with IPv6 stack enabled.
>>
>> This case was missed in JDK-8187450 / #2963.
>>
>> I verified that with this patch app
On Wed, 28 Sep 2022 18:55:09 GMT, Viktor Klang (Oracle)
wrote:
> Removes the `defaultIndex`since it is no longer used.
Please update copyright years in NetworkInterface.java. Otherwise LGTM!
-
Marked as reviewed by dfuchs (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10471
On Wed, 28 Sep 2022 18:55:09 GMT, Viktor Klang (Oracle)
wrote:
> Removes the `defaultIndex`since it is no longer used.
Thanks! Please integrate and one of us will sponsor.
-
PR: https://git.openjdk.org/jdk/pull/10471
On Thu, 29 Sep 2022 10:23:57 GMT, Daniel Fuchs wrote:
>> The constructor "MalformedURLException (Throwable cause)" doens'nt exist.
>> Isn't there any other method?
>
> You can use `Throwable::initCause`
var mfue = new MalformedURLException(e.getMes
On Thu, 29 Sep 2022 09:55:17 GMT, KIRIYAMA Takuya wrote:
>> src/java.base/share/classes/sun/net/www/protocol/ftp/Handler.java line 66:
>>
>>> 64: connection = new FtpURLConnection(u, p);
>>> 65: } catch (IllegalArgumentException e) {
>>> 66: throw new MalformedURL
On Fri, 30 Sep 2022 09:10:05 GMT, Jaikiran Pai wrote:
> Can I please get a review for this test-only change which proposes to improve
> the test run duration of `java/net/vthread/HttpALot.java` test, on Linux?
> This relates to https://bugs.openjdk.org/browse/JDK-8294610
>
> Experiments have s
On Fri, 30 Sep 2022 09:11:30 GMT, KIRIYAMA Takuya wrote:
>> I fixed sun.net.www.ParseUtil.decode().
>>
>> ParseUtil.decode() always tries to decode after parsing '%', so if '%' is
>> located at the end of the String, IndexOutOfBoundsException is thrown. Also,
>> if '%' is shown after decodable
On Fri, 30 Sep 2022 10:59:09 GMT, Alan Bateman wrote:
>> test/jdk/java/net/vthread/HttpALot.java line 26:
>>
>>> 24: /**
>>> 25: * @test
>>> 26: * @bug 8294610
>>
>> is this tag valid for a test fix -- afaik it is for a "product code fix"
>> i.e. the test is for a fix in the product code ide
On Fri, 30 Sep 2022 10:39:37 GMT, Claes Redestad wrote:
> Move a simple utility method from `URL` to the shared `sun.net.util.URLUtil`
> class, rename it for clarity and enhance it so that it returns the string
> literal if the protocol matches one of the tested variants. This helps reduce
> d
On Fri, 30 Sep 2022 11:43:15 GMT, Claes Redestad wrote:
>> Move a simple utility method from `URL` to the shared `sun.net.util.URLUtil`
>> class, rename it for clarity and enhance it so that it returns the string
>> literal if the protocol matches one of the tested variants. This helps
>> redu
On Fri, 30 Sep 2022 11:46:39 GMT, Claes Redestad wrote:
>> Move a simple utility method from `URL` to the shared `sun.net.util.URLUtil`
>> class, rename it for clarity and enhance it so that it returns the string
>> literal if the protocol matches one of the tested variants. This helps
>> redu
On Fri, 30 Sep 2022 12:18:51 GMT, Mark Sheppard wrote:
>> Hello Mark, it hasn't always been clear to me when to update the `@bug`. The
>> contribution guide isn't completely clear either. So I usually update the
>> bug id if the test change is substantial (in the way it affects the test).
>> I
On Fri, 30 Sep 2022 09:11:30 GMT, KIRIYAMA Takuya wrote:
>> I fixed sun.net.www.ParseUtil.decode().
>>
>> ParseUtil.decode() always tries to decode after parsing '%', so if '%' is
>> located at the end of the String, IndexOutOfBoundsException is thrown. Also,
>> if '%' is shown after decodable
Many built-in URL Handlers perform additional syntax checking on the URL when
`URLStreamHandler::openConnection` / connect is called. In some cases, some of
these checks could be also performed earlier, when `URLStreamHandler::parseURL`
is called.
This fix proposes to slightly modify the behavi
On Mon, 3 Oct 2022 14:35:46 GMT, Daniel Jeliński wrote:
> This PR reduces the execution time of ProxyAuthTest.
>
> Before this change the test always required at least 3 minutes to complete
> (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
> After this change the te
On Tue, 4 Oct 2022 07:04:42 GMT, Daniel Jeliński wrote:
>> This PR reduces the execution time of ProxyAuthTest.
>>
>> Before this change the test always required at least 3 minutes to complete
>> (6x 30 seconds timeout in `SSLSocketTemplate`'s `sslServerSocket.accept()`).
>> After this change t
1 - 100 of 1683 matches
Mail list logo
