From hannesw at openjdk.java.net  Wed May  5 15:09:17 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 5 May 2021 15:09:17 GMT
Subject: RFR: JDK-8262992: Improve `@see` output [v6]
In-Reply-To: <hGCAz45I65g0ZLZRQmi4Vy8aEjdTH57tk5woHEgwuCM=.271752e7-af71-4a8c-b820-0e5923d2f845@github.com>
References: <hGCAz45I65g0ZLZRQmi4Vy8aEjdTH57tk5woHEgwuCM=.271752e7-af71-4a8c-b820-0e5923d2f845@github.com>
Message-ID: <tJVYW7F8dkH7l5DjrO1jM6Cx9QRtjdtJUd4VThC97Xg=.44433d09-1a9a-4777-ad5f-4fe602ebe1fa@github.com>

> This changes the output for `@see` tags to a `<ul>` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. 
> 
> The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases.
> 
> As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values.

Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8262992
 - Put enum constants into alphabetical order.
 - Adapt new test
 - Merge branch 'master' into JDK-8262992
 - Update `@see` tag in class java.security.cert.PKIXRevocationChecker
 - JDK-8262992: Improve `@see` output

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2894/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2894&range=05
  Stats: 414 lines in 23 files changed: 187 ins; 20 del; 207 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2894.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2894/head:pull/2894

PR: https://git.openjdk.java.net/jdk/pull/2894

From jjg at openjdk.java.net  Thu May  6 20:12:58 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 6 May 2021 20:12:58 GMT
Subject: RFR: JDK-8262992: Improve `@see` output [v6]
In-Reply-To: <tJVYW7F8dkH7l5DjrO1jM6Cx9QRtjdtJUd4VThC97Xg=.44433d09-1a9a-4777-ad5f-4fe602ebe1fa@github.com>
References: <hGCAz45I65g0ZLZRQmi4Vy8aEjdTH57tk5woHEgwuCM=.271752e7-af71-4a8c-b820-0e5923d2f845@github.com>
 <tJVYW7F8dkH7l5DjrO1jM6Cx9QRtjdtJUd4VThC97Xg=.44433d09-1a9a-4777-ad5f-4fe602ebe1fa@github.com>
Message-ID: <Gr7MPY17vWUNouNfkpkZ5tGVI2mhevKB1B30W1OZjqY=.f5d8abc2-ead2-4c2b-a3bf-1d3983564f0e@github.com>

On Wed, 5 May 2021 15:09:17 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This changes the output for `@see` tags to a `<ul>` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. 
>> 
>> The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases.
>> 
>> As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values.
>
> Hannes Walln?fer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8262992
>  - Put enum constants into alphabetical order.
>  - Adapt new test
>  - Merge branch 'master' into JDK-8262992
>  - Update `@see` tag in class java.security.cert.PKIXRevocationChecker
>  - JDK-8262992: Improve `@see` output

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2894

From hannesw at openjdk.java.net  Fri May  7 10:49:04 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 7 May 2021 10:49:04 GMT
Subject: Integrated: JDK-8262992: Improve `@see` output
In-Reply-To: <hGCAz45I65g0ZLZRQmi4Vy8aEjdTH57tk5woHEgwuCM=.271752e7-af71-4a8c-b820-0e5923d2f845@github.com>
References: <hGCAz45I65g0ZLZRQmi4Vy8aEjdTH57tk5woHEgwuCM=.271752e7-af71-4a8c-b820-0e5923d2f845@github.com>
Message-ID: <c0UBAolfe-2aGEuRv7sbZMeYdQr7j6RqMzSCkmsHae4=.bec46478-1702-487d-9d0e-f296d563ae89@github.com>

On Tue, 9 Mar 2021 15:04:35 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> This changes the output for `@see` tags to a `<ul>` structure. A different CSS style is used if any of the `@see` tag labels are longer than 30 characters or contain a comma. 
> 
> The layout for the default CSS style is similar to the one we had so far with multiple links displayed inline and separated by commas. The CSS style for lists containing longer labels displays the list in block mode, but still separated by commas and without list markers. Note that the commas are generated via CSS in both cases.
> 
> As expected, there's a lot of test churn with this change. I converted some tests to text blocks that were still using old style string concatenation. In `TestSingletonLists.java` I had to exclude `@see` lists from the singleton check as javadoc generates a "See also" item for constant field values.

This pull request has now been integrated.

Changeset: e0c86884
Author:    Hannes Walln?fer <hannesw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e0c86884e56c0f826f7c1626abdcbb9926b297fb
Stats:     414 lines in 23 files changed: 187 ins; 20 del; 207 mod

8262992: Improve `@see` output

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/2894

From dfuchs at openjdk.java.net  Fri May  7 20:12:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 7 May 2021 20:12:48 GMT
Subject: RFR: 8266761: AssertionError in
 sun.net.httpserver.ServerImpl.responseCompleted
Message-ID: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>

Hi,

Please find here a fix to prevent an assertion error from firing in the com.sun.net.httpserver.

The issue occurs systematically when all of these conditions are met:

1. System assertions are enabled
2. The handler doesn't read or close the request input stream
3. The handler sends a reply with no content (just headers, but no body)
3. The handler doesn't close the response output stream
4. The handler doesn't close the HttpExchange

The test fails with the assertion error when run without the fix (provided system assertions are enabled) and passes with the fix.

-------------

Commit messages:
 - 8266761: AssertionError in sun.net.httpserver.ServerImpl.responseCompleted

Changes: https://git.openjdk.java.net/jdk/pull/3923/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3923&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266761
  Stats: 198 lines in 3 files changed: 194 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3923/head:pull/3923

PR: https://git.openjdk.java.net/jdk/pull/3923

From sormuras at gmail.com  Sun May  9 06:47:12 2021
From: sormuras at gmail.com (Christian Stein)
Date: Sun, 9 May 2021 08:47:12 +0200
Subject: New candidate JEP: 408: Simple Web Server
In-Reply-To: <20210329191606.929913DDF64@eggemoggin.niobe.net>
References: <20210329191606.929913DDF64@eggemoggin.niobe.net>
Message-ID: <CAJi8+g6iQGTAf4hdSUjcuEwvR6QaBKKDogj78hEYOaH=KnRpeQ@mail.gmail.com>

Motivated by the summary of JEP 408, I finally wrote a small blog[1]
about an in-memory http handler that I use for testing browsing-related
code via URL.open..., HttpClient, or other ways to read a resource.

The basic idea is to map a prepared response (http code, bytes, and
content-type) to a request path. For example:

  "/index.html" -> "<html><body><h1>Index</h1></body></html>"

Perhaps, this path-asset(resource)-mapping abstraction is useful for
somebody else, too.

Cheers,
Christian

[1]:
https://sormuras.github.io/blog/2021-05-09-in-memory-http-server-handler


On Mon, Mar 29, 2021 at 9:16 PM <mark.reinhold at oracle.com> wrote:

> https://openjdk.java.net/jeps/408
>
>   Summary: Provide a command-line tool to start a minimal web server
>   that serves static files in the current directory. This low-threshold
>   utility will be useful for prototyping, ad-hoc coding, and testing
>   purposes, particularly in educational contexts.
>
> - Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210509/5375883e/attachment.htm>

From dfuchs at openjdk.java.net  Mon May 10 19:13:47 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 10 May 2021 19:13:47 GMT
Subject: RFR: 8266761: AssertionError in
 sun.net.httpserver.ServerImpl.responseCompleted [v2]
In-Reply-To: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
References: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
Message-ID: <fBfKHlcamDGCNq4O2mpn9_ZUmcijW7P098D9uUoEOLM=.88afd1ef-cf62-4033-9b24-0b13c990cfd5@github.com>

> Hi,
> 
> Please find here a fix to prevent an assertion error from firing in the com.sun.net.httpserver.
> 
> The issue occurs systematically when all of these conditions are met:
> 
> 1. System assertions are enabled
> 2. The handler doesn't read or close the request input stream
> 3. The handler sends a reply with no content (just headers, but no body)
> 3. The handler doesn't close the response output stream
> 4. The handler doesn't close the HttpExchange
> 
> The test fails with the assertion error when run without the fix (provided system assertions are enabled) and passes with the fix.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Added a second test case which triggers the assertion under different conditions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3923/files
  - new: https://git.openjdk.java.net/jdk/pull/3923/files/4bcfb5e4..23cc8913

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3923&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3923&range=00-01

  Stats: 75 lines in 1 file changed: 60 ins; 7 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3923/head:pull/3923

PR: https://git.openjdk.java.net/jdk/pull/3923

From dfuchs at openjdk.java.net  Mon May 10 19:31:32 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 10 May 2021 19:31:32 GMT
Subject: RFR: 8266761: AssertionError in
 sun.net.httpserver.ServerImpl.responseCompleted [v3]
In-Reply-To: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
References: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
Message-ID: <fkfBwAfX1LfudX6q0Sd0vyXMSGtNB5GOXQjlN5ZSzK8=.96d9b61c-e58f-4836-9275-fc25c1680ee1@github.com>

> Hi,
> 
> Please find here a fix to prevent an assertion error from firing in the com.sun.net.httpserver.
> 
> The issue occurs systematically when all of these conditions are met:
> 
> 1. System assertions are enabled
> 2. The handler doesn't read or close the request input stream
> 3. The handler sends a reply with no content (just headers, but no body)
> 3. The handler doesn't close the response output stream
> 4. The handler doesn't close the HttpExchange
> 
> The test fails with the assertion error when run without the fix (provided system assertions are enabled) and passes with the fix.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Removed obsolete comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3923/files
  - new: https://git.openjdk.java.net/jdk/pull/3923/files/23cc8913..0ff70363

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3923&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3923&range=01-02

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3923.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3923/head:pull/3923

PR: https://git.openjdk.java.net/jdk/pull/3923

From chegar at openjdk.java.net  Tue May 11 08:15:56 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 11 May 2021 08:15:56 GMT
Subject: RFR: 8266761: AssertionError in
 sun.net.httpserver.ServerImpl.responseCompleted [v3]
In-Reply-To: <fkfBwAfX1LfudX6q0Sd0vyXMSGtNB5GOXQjlN5ZSzK8=.96d9b61c-e58f-4836-9275-fc25c1680ee1@github.com>
References: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
 <fkfBwAfX1LfudX6q0Sd0vyXMSGtNB5GOXQjlN5ZSzK8=.96d9b61c-e58f-4836-9275-fc25c1680ee1@github.com>
Message-ID: <EGfbh3fqJhZhSdDZhl5DFd30jndA-VK6gjXI5764qM0=.0a65b51d-d796-4e91-870c-2bf487ad2b6c@github.com>

On Mon, 10 May 2021 19:31:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find here a fix to prevent an assertion error from firing in the com.sun.net.httpserver.
>> 
>> The issue occurs systematically when all of these conditions are met:
>> 
>> 1. System assertions are enabled
>> 2. The handler doesn't read or close the request input stream
>> 3. The handler sends a reply with no content (just headers, but no body)
>> 3. The handler doesn't close the response output stream
>> 4. The handler doesn't close the HttpExchange
>> 
>> The test fails with the assertion error when run without the fix (provided system assertions are enabled) and passes with the fix.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed obsolete comments

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3923

From dfuchs at openjdk.java.net  Tue May 11 14:52:22 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 11 May 2021 14:52:22 GMT
Subject: Integrated: 8266761: AssertionError in
 sun.net.httpserver.ServerImpl.responseCompleted
In-Reply-To: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
References: <DgfwdJrfjRyd-r4bKyrkPp4NU2cCm5X8suuiToOSB7E=.1524c360-3a71-43e4-9483-982b611d6b80@github.com>
Message-ID: <ETDb4lg-wBhSNXqNJrfF5-T76nR9abBcFPu7tyh7sZ4=.ac7fdf97-b6bc-407f-bc5c-245ca3487069@github.com>

On Fri, 7 May 2021 18:38:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here a fix to prevent an assertion error from firing in the com.sun.net.httpserver.
> 
> The issue occurs systematically when all of these conditions are met:
> 
> 1. System assertions are enabled
> 2. The handler doesn't read or close the request input stream
> 3. The handler sends a reply with no content (just headers, but no body)
> 3. The handler doesn't close the response output stream
> 4. The handler doesn't close the HttpExchange
> 
> The test fails with the assertion error when run without the fix (provided system assertions are enabled) and passes with the fix.

This pull request has now been integrated.

Changeset: 2d2cd78b
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2d2cd78bde7bb9101614a1ba2285d1e37d5d3249
Stats:     245 lines in 3 files changed: 241 ins; 4 del; 0 mod

8266761: AssertionError in sun.net.httpserver.ServerImpl.responseCompleted

Reviewed-by: chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3923

From chris.hegarty at oracle.com  Wed May 12 10:58:54 2021
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 12 May 2021 10:58:54 +0000
Subject: CFV: New Networking Group Member: Daniel Fuchs
Message-ID: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>

I hereby nominate Daniel Fuchs to Membership in the Networking
Group.

Daniel is a Reviewer in the JDK project, and a long term contributor to
the Java platform. Daniel has been actively participating in the
evolution and maintenance of the networking libraries for several years.
Daniel was a significant contributor to the HTTP Client (JEP 321), and
more recently lead the reimplementation of DatagramSocket (JEP 373), in
preparation for virtual threads.

Votes are due by 11:00 UTC Wednesday, 26 May 2021.

Only current Members of the Networking Group [1] are eligible
to vote on this nomination. Votes must be cast in the open by
replying to this mailing list

For Lazy Consensus voting instructions, see [2].

-Chris

[1] https://openjdk.java.net/census#net
[2] https://openjdk.java.net/groups/#member-vote


From chris.hegarty at oracle.com  Wed May 12 11:02:18 2021
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 12 May 2021 11:02:18 +0000
Subject: CFV: New Networking Group Member: Daniel Fuchs
In-Reply-To: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
References: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
Message-ID: <D832E9B5-C514-4152-BD77-AF4F7B99F8A5@oracle.com>

Vote: YES

-Chris.

> On 12 May 2021, at 11:58, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> I hereby nominate Daniel Fuchs to Membership in the Networking
> Group.

From Alan.Bateman at oracle.com  Wed May 12 11:03:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 May 2021 12:03:35 +0100
Subject: CFV: New Networking Group Member: Daniel Fuchs
In-Reply-To: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
References: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
Message-ID: <41969075-17b4-a299-f538-ea0e4cd92d9e@oracle.com>

Vote: yes

From michael.x.mcmahon at oracle.com  Wed May 12 11:12:57 2021
From: michael.x.mcmahon at oracle.com (Michael McMahon)
Date: Wed, 12 May 2021 12:12:57 +0100
Subject: CFV: New Networking Group Member: Daniel Fuchs
In-Reply-To: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
References: <6BE4DF23-108E-477C-A856-4E9511026D78@oracle.com>
Message-ID: <aea64c18-6cf8-afe4-2bc6-562131b0ea65@oracle.com>

Vote: Yes

On 12/05/2021 11:58, Chris Hegarty wrote:
> I hereby nominate Daniel Fuchs to Membership in the Networking
> Group.
>
> Daniel is a Reviewer in the JDK project, and a long term contributor to
> the Java platform. Daniel has been actively participating in the
> evolution and maintenance of the networking libraries for several years.
> Daniel was a significant contributor to the HTTP Client (JEP 321), and
> more recently lead the reimplementation of DatagramSocket (JEP 373), in
> preparation for virtual threads.
>
> Votes are due by 11:00 UTC Wednesday, 26 May 2021.
>
> Only current Members of the Networking Group [1] are eligible
> to vote on this nomination. Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> -Chris
>
> [1] https://openjdk.java.net/census#net
> [2] https://openjdk.java.net/groups/#member-vote
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210512/7c6b4e9f/attachment.htm>

From krzysztof.krason at gmail.com  Fri May 14 19:37:57 2021
From: krzysztof.krason at gmail.com (Krzysztof K.)
Date: Fri, 14 May 2021 21:37:57 +0200
Subject: Issue with HTTP/2 communicating with GCP servers with TE: Trailers
Message-ID: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>

Hi,
I have an issue using http client communicating with servers that most
probably are on GCP (I see header: "via: 1.1 google").

I get "java.io.IOException: Received RST_STREAM: Protocol error".
I quick search revealed that there were two bugs reported in JDK for that,
with the most recent (https://bugs.openjdk.java.net/browse/JDK-8218546)
should have fixed the issue in JDK 12.

But I'm on JDK 16 (build 16+35-2229) and I get this error when connecting
to a website when I use the header "TE: Trailers"  (needs first letter
capitalized).

When I remove this header everything works, if I switch to HTTP 1.1 (with
that header) it also works.

Here is a minimal reproducible example:

HttpClient.newBuilder()
  .build()
  .send(
    HttpRequest.newBuilder()
    .header("TE", "Trailers")
    .uri(URI.create("https://pacjent.erejestracja.ezdrowie.gov.pl"))
    .GET()
    .build(),
    HttpResponse.BodyHandlers.ofString()
  );

I got that header from the browser (I tried to use the same request in Java
as Firefox does) and was surprised that it works in browser (Firefox 90) as
well as in curl (7.74.0) but fails in Java.

Not sure if that is a quirk of Google servers or java bug, so I'm reporting
here.


Below is full stacktrace:

 java.io.IOException: Received RST_STREAM: Protocol error
at jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:568)
~[java.net.http:?]
at jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:119)
~[java.net.http:?]
at com.kirela.szczepimy.Main.webSearch(Main.java:525) ~[classes/:?]
at com.kirela.szczepimy.Main.main(Main.java:423) [classes/:?]
Caused by: java.io.IOException: Received RST_STREAM: Protocol error
at jdk.internal.net.http.Stream.handleReset(Stream.java:537)
~[java.net.http:?]
at jdk.internal.net.http.Stream.schedule(Stream.java:184) ~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
~[java.net.http:?]
at jdk.internal.net.http.Stream.receiveResetFrame(Stream.java:345)
~[java.net.http:?]
at jdk.internal.net.http.Stream.incoming_reset(Stream.java:515)
~[java.net.http:?]
at jdk.internal.net.http.Stream.otherFrame(Stream.java:455)
~[java.net.http:?]
at jdk.internal.net.http.Stream.incoming(Stream.java:448) ~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection.processFrame(Http2Connection.java:810)
~[java.net.http:?]
at jdk.internal.net.http.frame.FramesDecoder.decode(FramesDecoder.java:155)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection$FramesController.processReceivedData(Http2Connection.java:232)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection.asyncReceive(Http2Connection.java:672)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection$Http2TubeSubscriber.processQueue(Http2Connection.java:1305)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection$Http2TubeSubscriber.runOrSchedule(Http2Connection.java:1323)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection$Http2TubeSubscriber.onNext(Http2Connection.java:1349)
~[java.net.http:?]
at
jdk.internal.net.http.Http2Connection$Http2TubeSubscriber.onNext(Http2Connection.java:1283)
~[java.net.http:?]
at
jdk.internal.net.http.common.SSLTube$DelegateWrapper.onNext(SSLTube.java:210)
~[java.net.http:?]
at
jdk.internal.net.http.common.SSLTube$SSLSubscriberWrapper.onNext(SSLTube.java:492)
~[java.net.http:?]
at
jdk.internal.net.http.common.SSLTube$SSLSubscriberWrapper.onNext(SSLTube.java:295)
~[java.net.http:?]
at
jdk.internal.net.http.common.SubscriberWrapper$DownstreamPusher.run1(SubscriberWrapper.java:316)
~[java.net.http:?]
at
jdk.internal.net.http.common.SubscriberWrapper$DownstreamPusher.run(SubscriberWrapper.java:259)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:271)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler.runOrSchedule(SequentialScheduler.java:224)
~[java.net.http:?]
at
jdk.internal.net.http.common.SubscriberWrapper.outgoing(SubscriberWrapper.java:232)
~[java.net.http:?]
at
jdk.internal.net.http.common.SubscriberWrapper.outgoing(SubscriberWrapper.java:198)
~[java.net.http:?]
at
jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData(SSLFlowDelegate.java:444)
~[java.net.http:?]
at
jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run(SSLFlowDelegate.java:268)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run(SequentialScheduler.java:175)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:147)
~[java.net.http:?]
at
jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:198)
~[java.net.http:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
~[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
~[?:?]
at java.lang.Thread.run(Thread.java:831) ~[?:?]


Regards,
-- 
Krzysztof Krason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210514/82177606/attachment.htm>

From jai.forums2013 at gmail.com  Sat May 15 11:43:20 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 15 May 2021 17:13:20 +0530
Subject: Issue with HTTP/2 communicating with GCP servers with TE: Trailers
In-Reply-To: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>
References: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>
Message-ID: <1be8d852-8212-52d0-970b-918fd58e1cb7@gmail.com>

Hello Krzysztof,

On 15/05/21 1:07 am, Krzysztof K. wrote:
> Hi,
> I have an issue using http client communicating with servers that most 
> probably are on GCP (I see header: "via: 1.1 google").
>
> I get "java.io.IOException: Received RST_STREAM: Protocol error".
> ...
>
> But I'm on JDK 16 (build 16+35-2229) and I get this error when 
> connecting to a website when I use the header "TE: Trailers"? (needs 
> first letter capitalized).
>
> When I remove this header everything works, if I switch to HTTP 1.1 
> (with that header) it also works.
>
> Here is a minimal reproducible example:
>
> HttpClient.newBuilder()
> ? .build()
> ? .send(
> ??? HttpRequest.newBuilder()
> ??? .header("TE", "Trailers")

IMO, this is more of an application issue than the JDK. In HTTP/2 the TE 
header[1] is expected to only have the value "trailers" (case sensitive) 
as noted here[2]. If you change your code to use "trailers" instead of 
"Trailers" it works (as you seem to have noticed). As for why it works 
in Firefox or curl, I'm not sure - perhaps they have special handling of 
this specific header to lower case its value if it's "Trailers"?


[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/TE

[2] https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2.2


-Jaikiran



From jai.forums2013 at gmail.com  Sat May 15 12:02:48 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 15 May 2021 17:32:48 +0530
Subject: Issue with HTTP/2 communicating with GCP servers with TE: Trailers
In-Reply-To: <1be8d852-8212-52d0-970b-918fd58e1cb7@gmail.com>
References: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>
 <1be8d852-8212-52d0-970b-918fd58e1cb7@gmail.com>
Message-ID: <796e752e-c902-a093-8761-d17ea572e384@gmail.com>


On 15/05/21 5:13 pm, Jaikiran Pai wrote:
> Hello Krzysztof,
>
> On 15/05/21 1:07 am, Krzysztof K. wrote:
>> Hi,
>> I have an issue using http client communicating with servers that 
>> most probably are on GCP (I see header: "via: 1.1 google").
>>
>> I get "java.io.IOException: Received RST_STREAM: Protocol error".
>> ...
>>
>> But I'm on JDK 16 (build 16+35-2229) and I get this error when 
>> connecting to a website when I use the header "TE: Trailers" (needs 
>> first letter capitalized).
>>
>> When I remove this header everything works, if I switch to HTTP 1.1 
>> (with that header) it also works.
>>
>> Here is a minimal reproducible example:
>>
>> HttpClient.newBuilder()
>> ? .build()
>> ? .send(
>> ??? HttpRequest.newBuilder()
>> ??? .header("TE", "Trailers")
>
> IMO, this is more of an application issue than the JDK. In HTTP/2 the 
> TE header[1] is expected to only have the value "trailers" (case 
> sensitive) as noted here[2]. If you change your code to use "trailers" 
> instead of "Trailers" it works (as you seem to have noticed). As for 
> why it works in Firefox or curl, I'm not sure - perhaps they have 
> special handling of this specific header to lower case its value if 
> it's "Trailers"?

A quick check of the curl source code[1] suggests that it does indeed do 
special handling of this TE request param[2]. It seems to do a 
case-insensitive check[3] of the user passed value for "TE" header and 
if it finds that it's "trailers" (case-insensitive) then it just 
overwrites that header value with the literal "trailers" before issuing 
the request. I guess Firefox has something similar.


[1] https://github.com/curl/curl

[2] 
https://github.com/curl/curl/blob/455a63c66f188598275e87d32de2c4e8e26b80cb/lib/http2.c#L1851

[3] 
https://github.com/curl/curl/blob/455a63c66f188598275e87d32de2c4e8e26b80cb/lib/http2.c#L1830

-Jaikiran



From jai.forums2013 at gmail.com  Sat May 15 12:05:27 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 15 May 2021 17:35:27 +0530
Subject: Issue with HTTP/2 communicating with GCP servers with TE: Trailers
In-Reply-To: <796e752e-c902-a093-8761-d17ea572e384@gmail.com>
References: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>
 <1be8d852-8212-52d0-970b-918fd58e1cb7@gmail.com>
 <796e752e-c902-a093-8761-d17ea572e384@gmail.com>
Message-ID: <988602b3-d3db-c498-3669-8a0a01e8a655@gmail.com>


On 15/05/21 5:32 pm, Jaikiran Pai wrote:
>
> On 15/05/21 5:13 pm, Jaikiran Pai wrote:
>> Hello Krzysztof,
>>
>> On 15/05/21 1:07 am, Krzysztof K. wrote:
>>> Hi,
>>> I have an issue using http client communicating with servers that 
>>> most probably are on GCP (I see header: "via: 1.1 google").
>>>
>>> I get "java.io.IOException: Received RST_STREAM: Protocol error".
>>> ...
>>>
>>> But I'm on JDK 16 (build 16+35-2229) and I get this error when 
>>> connecting to a website when I use the header "TE: Trailers" (needs 
>>> first letter capitalized).
>>>
>>> When I remove this header everything works, if I switch to HTTP 1.1 
>>> (with that header) it also works.
>>>
>>> Here is a minimal reproducible example:
>>>
>>> HttpClient.newBuilder()
>>> ? .build()
>>> ? .send(
>>> ??? HttpRequest.newBuilder()
>>> ??? .header("TE", "Trailers")
>>
>> IMO, this is more of an application issue than the JDK. In HTTP/2 the 
>> TE header[1] is expected to only have the value "trailers" (case 
>> sensitive) as noted here[2]. If you change your code to use 
>> "trailers" instead of "Trailers" it works (as you seem to have 
>> noticed). As for why it works in Firefox or curl, I'm not sure - 
>> perhaps they have special handling of this specific header to lower 
>> case its value if it's "Trailers"?
>
> A quick check of the curl source code[1] suggests that it does indeed 
> do special handling of this TE request param[2].

I meant request header.

-Jaikiran


From jboes at openjdk.java.net  Mon May 17 10:01:18 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 17 May 2021 10:01:18 GMT
Subject: RFR: 8266897: com/sun/net/httpserver/FilterTest.java fails
 intermittently with AssertionError
Message-ID: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>

The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. 
This fix uses a `CompletableFuture` to ensure the test value has been updated before it is asserted.

While here, the change increases the thread-safety of the filter state of a context.

-------------

Commit messages:
 - Merge branch 'master' into 8266897
 - Use CompletableFuture in test and use concurrent collections to hold filters

Changes: https://git.openjdk.java.net/jdk/pull/4050/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4050&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266897
  Stats: 31 lines in 3 files changed: 3 ins; 4 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4050.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4050/head:pull/4050

PR: https://git.openjdk.java.net/jdk/pull/4050

From chegar at openjdk.java.net  Mon May 17 11:07:04 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 17 May 2021 11:07:04 GMT
Subject: RFR: 8266897: com/sun/net/httpserver/FilterTest.java fails
 intermittently with AssertionError
In-Reply-To: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
References: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
Message-ID: <iX8WLZfK3azh3lbLJbWlwIzk1IObS1Dx0CtXpNKBowo=.beca2de6-c787-4ab7-ae9d-c586168d7b22@github.com>

On Mon, 17 May 2021 09:53:06 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. 
> This fix uses a `CompletableFuture` to ensure the test value has been updated before it is asserted.
> 
> While here, the change increases the thread-safety of the filter state of a context.

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4050

From dfuchs at openjdk.java.net  Mon May 17 11:39:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 17 May 2021 11:39:44 GMT
Subject: RFR: 8266897: com/sun/net/httpserver/FilterTest.java fails
 intermittently with AssertionError
In-Reply-To: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
References: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
Message-ID: <AtcHaVjjpiDyWopf8T0LYyHdVnVmNVSCXQVXH-6KjGw=.e941536d-8b33-4ca2-b134-513a9d7da22b@github.com>

On Mon, 17 May 2021 09:53:06 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. 
> This fix uses a `CompletableFuture` to ensure the test value has been updated before it is asserted.
> 
> While here, the change increases the thread-safety of the filter state of a context.

LGTM!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4050

From powers.anirvan at gmail.com  Mon May 17 16:37:04 2021
From: powers.anirvan at gmail.com (Anirvan Sarkar)
Date: Tue, 18 May 2021 01:37:04 +0900
Subject: Issue with HTTP/2 communicating with GCP servers with TE: Trailers
In-Reply-To: <988602b3-d3db-c498-3669-8a0a01e8a655@gmail.com>
References: <CAF+zKUMODRf692Go-7M1DzNoSO=jwyA5h74ihYwgi6gyEjAUGA@mail.gmail.com>
 <1be8d852-8212-52d0-970b-918fd58e1cb7@gmail.com>
 <796e752e-c902-a093-8761-d17ea572e384@gmail.com>
 <988602b3-d3db-c498-3669-8a0a01e8a655@gmail.com>
Message-ID: <CAEQxcvF-HVyiXGVJRaG5Pe+imC3am0wZ2iZY4Hpi7d1jjeNhyw@mail.gmail.com>

Hi,

I think Firefox Developer Tools should not display the TE request header
value as "Trailers" since this is not a valid value as per the
specification, and it is actually sending "trailers" over the wire [1].

I have submitted a bug regarding this [2].

[1] :
https://hg.mozilla.org/mozilla-central/file/5de53d489b7d5613710a40b2c64693dbab31e8ee/netwerk/protocol/http/Http2Compression.cpp#l1167
[2] : https://bugzilla.mozilla.org/show_bug.cgi?id=1711482

On Sat, 15 May 2021 at 21:05, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:

>
> On 15/05/21 5:32 pm, Jaikiran Pai wrote:
> >
> > On 15/05/21 5:13 pm, Jaikiran Pai wrote:
> >> Hello Krzysztof,
> >>
> >> On 15/05/21 1:07 am, Krzysztof K. wrote:
> >>> Hi,
> >>> I have an issue using http client communicating with servers that
> >>> most probably are on GCP (I see header: "via: 1.1 google").
> >>>
> >>> I get "java.io.IOException: Received RST_STREAM: Protocol error".
> >>> ...
> >>>
> >>> But I'm on JDK 16 (build 16+35-2229) and I get this error when
> >>> connecting to a website when I use the header "TE: Trailers" (needs
> >>> first letter capitalized).
> >>>
> >>> When I remove this header everything works, if I switch to HTTP 1.1
> >>> (with that header) it also works.
> >>>
> >>> Here is a minimal reproducible example:
> >>>
> >>> HttpClient.newBuilder()
> >>>   .build()
> >>>   .send(
> >>>     HttpRequest.newBuilder()
> >>>     .header("TE", "Trailers")
> >>
> >> IMO, this is more of an application issue than the JDK. In HTTP/2 the
> >> TE header[1] is expected to only have the value "trailers" (case
> >> sensitive) as noted here[2]. If you change your code to use
> >> "trailers" instead of "Trailers" it works (as you seem to have
> >> noticed). As for why it works in Firefox or curl, I'm not sure -
> >> perhaps they have special handling of this specific header to lower
> >> case its value if it's "Trailers"?
> >
> > A quick check of the curl source code[1] suggests that it does indeed
> > do special handling of this TE request param[2].
>
> I meant request header.
>
> -Jaikiran
>
>

-- 
Anirvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210518/57c4b6c2/attachment.htm>

From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

-------------

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

-------------

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jYnPM3TGZaiZyNdO1TqYy5zWEHeqaEJH6dbp1xhiIHI=.213bd236-b2df-44d8-8f34-a963a3ffdfb6@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream<File> filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream<File> fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream<File> fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction<InputStream>() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List<Configuration> configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class<?> clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class<?> clazz) {


**That's all**.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <wihzX2vMKBxcpu3CE2BaQNZ1jyXj8e2Fbps1z0CJMlU=.e234b050-b1b0-4280-b764-9a409d5cf428@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <JhTe209ZxiIMoOvppz7-1xRxGS2Rb-YiyJnD7OzZDp0=.73ed4efc-2751-4746-b5d2-1bfd327574a6@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From michaelm at openjdk.java.net  Tue May 18 08:16:48 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Tue, 18 May 2021 08:16:48 GMT
Subject: RFR: 8266897: com/sun/net/httpserver/FilterTest.java fails
 intermittently with AssertionError
In-Reply-To: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
References: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
Message-ID: <9PjY2z-ndDAXIcCOOWMNx3kj0QpW3qvxEdQIf9f5cGM=.91af3c5e-81d2-4c3a-837e-c68e1883a3ca@github.com>

On Mon, 17 May 2021 09:53:06 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. 
> This fix uses a `CompletableFuture` to ensure the test value has been updated before it is asserted.
> 
> While here, the change increases the thread-safety of the filter state of a context.

LGTM

-------------

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4050

From jboes at openjdk.java.net  Tue May 18 09:15:41 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 18 May 2021 09:15:41 GMT
Subject: Integrated: 8266897: com/sun/net/httpserver/FilterTest.java fails
 intermittently with AssertionError
In-Reply-To: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
References: <EoADKHCSAEXF43VU1yYd450Jnf3bia8i9IeZKbjLjWI=.cb31d470-3cd8-4dfe-942a-9951062dd27e@github.com>
Message-ID: <iuZJrdjjl5AeDt_bEGbW8gon1dRkSQ4lk2e6FsFBtpw=.04018330-b4ed-41b9-bf11-6bdfec30d6e6@github.com>

On Mon, 17 May 2021 09:53:06 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The tests for `afterHandler` filters expect the filter operation to happen before the assertion. Very rarely this is not the case, the calling thread reads the response before the filter operation is executed, so the test value is not set before it is asserted. 
> This fix uses a `CompletableFuture` to ensure the test value has been updated before it is asserted.
> 
> While here, the change increases the thread-safety of the filter state of a context.

This pull request has now been integrated.

Changeset: 894547d2
Author:    Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/894547d2c102dcbe1f9ec8a1edb11c6b31e4270e
Stats:     31 lines in 3 files changed: 3 ins; 4 del; 24 mod

8266897: com/sun/net/httpserver/FilterTest.java fails intermittently with AssertionError

Reviewed-by: chegar, dfuchs, michaelm

-------------

PR: https://git.openjdk.java.net/jdk/pull/4050

From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
Message-ID: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <N2_XwJPA2GmR6f-9AaDW51o_YSBeSnHbWvzlL1e6h9U=.bcb95509-e3f8-4345-a8d1-4636f727ab36@github.com>
Message-ID: <LP-JXhyiYZ4-yfHkeHX7Rqt-1AnCPesIf4uK5ycC8B4=.4459bddf-cc61-4c92-9b5e-4e046ede8a90@github.com>

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <vZ5Fh4wtC-MkWp1r_01i4HE4JNwcK9pdergEvHoSgWU=.b1d7af15-6777-427d-89e6-f41b3764f4de@github.com>
Message-ID: <z9kXH2Zm9AgECH3iihoXcgKisBj7HQMYB7SBmr98Hek=.c0ba0d9d-f3ea-427c-97a1-8de5843c0698@github.com>

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
Message-ID: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <lplEEwtimSj6Hov62R0Dq-dH7ONDKE9iSfOC34I-bjY=.16a2f4b0-defd-4813-b953-2f52fd9580cd@github.com>
 <lB6yCUb8KkJj-hUyrmKeSAfThazy7iXb-6ubiDirLDQ=.853b9708-b24c-4aed-9628-df931039cab2@github.com>
 <esxkLka5-RD9ZpREmbfbeYHokRW_8GwAKNBatpTfQ5I=.84ff2352-fb05-4ee9-8c1f-a82cc3572aed@github.com>
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <UN8g8sgK7nXvYjtZiSBUhCaU-0qEb8b7Y2OzhxgtOzY=.08a47c9a-a7a5-4a0e-8919-19d71fc19a4f@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <LgbU-sI0tWPZUqtoQA3U69H6-_YB1kKmqgTckkVcrlo=.0d7b35c2-aec5-41be-ab62-459a9ae8c7dd@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <NQ4IhVZC8LudCe-a1JsSFd95dtttKo46bw2iK0DkiQA=.1139a6e3-8acc-4099-b9ab-c599fdca20d2@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <Ep1azxH_vnemjxbvBu6HprCKjwMcG1nzTozdYIA1RtU=.e8be0928-e09f-483e-a775-06bbcce8be8c@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073

From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <L_strZt1H9X1vdJh8AYRIWExhJMfmODbsj-N8xQkvYw=.1e46863a-db33-4d33-bbe4-645f0c52b349@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <jVoctx_UzYbZpnzVpQJ-kVkDSiW8wpixKMGGDicrAfk=.e36178c6-303c-489c-813b-37842a110503@github.com>

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
Message-ID: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <eEEGNrlajsoNJnl9Vg6Honj8vVgUOZhlB8FGwQC4g30=.8bee927d-c84f-4c64-8bc5-1f6f4a7886a0@github.com>
 <hKwe9QmD6nhoEwXmo1wHkfXfPd7Va8rBMzaHemY__kw=.3f31f49d-7ddb-40a2-b87e-3430c7b29f05@github.com>
Message-ID: <NsAoXUFxz2QHQKrDb3O1Ls1jKyXBkfbmB9AubjXUDus=.6a87197e-b3bf-4971-a48e-6e7f008c9135@github.com>

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static <T> T doPrivileged(PrivilegedExceptionAction<T> action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Sean, Phil and Alan

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust order of VM options

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From jboes at openjdk.java.net  Wed May 19 09:10:51 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 19 May 2021 09:10:51 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API documentation
 of static methods
Message-ID: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>

The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

-------------

Commit messages:
 - address PR comment: update wording
 - Merge branch 'master' into 8267262
 - initial change

Changes: https://git.openjdk.java.net/jdk/pull/4085/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4085&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267262
  Stats: 49 lines in 2 files changed: 44 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4085/head:pull/4085

PR: https://git.openjdk.java.net/jdk/pull/4085

From dfuchs at openjdk.java.net  Wed May 19 09:10:52 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 19 May 2021 09:10:52 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <5N_lztRhR00CU3f4sBJSPD4DrCyBDB6GbrBUaFrHjdg=.c4305f6e-6800-46a5-a9f7-c688bd2fff44@github.com>

On Tue, 18 May 2021 09:34:25 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

Marked as reviewed by dfuchs (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 213:

> 211:      * Doing so is likely to fail, since the exchange has commonly been handled
> 212:      * before the {@code operation} is invoked. Correspondingly, the client
> 213:      * commonly receives the response before the filter operation is executed.

I'd rather replace `commonly` with `may`: this is essentially racy and you cannot assume that any of the outcome is more likely than the other.


     * [...]  Correspondingly, the client
     * may receive the response before the filter operation is executed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From chegar at openjdk.java.net  Wed May 19 09:10:52 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 19 May 2021 09:10:52 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <jGCwMXtfdB626a8celtTNA8EMjsxSoOrFw-x7cCLxPE=.8f352f45-90d1-4fae-8389-2c672a5e3114@github.com>

On Tue, 18 May 2021 09:34:25 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From chegar at openjdk.java.net  Wed May 19 09:10:53 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 19 May 2021 09:10:53 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods
In-Reply-To: <5N_lztRhR00CU3f4sBJSPD4DrCyBDB6GbrBUaFrHjdg=.c4305f6e-6800-46a5-a9f7-c688bd2fff44@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
 <5N_lztRhR00CU3f4sBJSPD4DrCyBDB6GbrBUaFrHjdg=.c4305f6e-6800-46a5-a9f7-c688bd2fff44@github.com>
Message-ID: <Tl6BmfX5vT2fAYp5Kc-9jugoFS1BLbUyeLTXDog5kW4=.d9617bea-9890-4e8a-9a85-6fc5fc6b639e@github.com>

On Tue, 18 May 2021 09:49:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 213:
> 
>> 211:      * Doing so is likely to fail, since the exchange has commonly been handled
>> 212:      * before the {@code operation} is invoked. Correspondingly, the client
>> 213:      * commonly receives the response before the filter operation is executed.
> 
> I'd rather replace `commonly` with `may`: this is essentially racy and you cannot assume that any of the outcome is more likely than the other.
> 
> 
>      * [...]  Correspondingly, the client
>      * may receive the response before the filter operation is executed.

Maybe rephrase? Who knows what the client will received, if anything - since the bytes will be sent over the network.

Maybe something like:
  More specifically, the response will typically be sent before the filter operation is executed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From jboes at openjdk.java.net  Wed May 19 09:19:56 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 19 May 2021 09:19:56 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods [v2]
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <cRIv9sThIVBKAaKuYW-0dSkZbImrptzGB_q6xsWF_tE=.e43ad528-0709-42b2-8cb6-25ac73770e33@github.com>

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

Julia Boes has updated the pull request incrementally with one additional commit since the last revision:

  add bug id to test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4085/files
  - new: https://git.openjdk.java.net/jdk/pull/4085/files/ef8ffbfe..8d3749b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4085&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4085&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4085/head:pull/4085

PR: https://git.openjdk.java.net/jdk/pull/4085

From dfuchs at openjdk.java.net  Wed May 19 09:19:57 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 19 May 2021 09:19:57 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <S63IZHh1E1pFYclAueAWlUQWqDDmyGwOhhK_z0FWFJs=.f54f538d-824a-419d-8017-99cb54199346@github.com>

On Tue, 18 May 2021 09:34:25 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

I suspect this need a CSR...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From michaelm at openjdk.java.net  Wed May 19 09:36:38 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Wed, 19 May 2021 09:36:38 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods [v2]
In-Reply-To: <cRIv9sThIVBKAaKuYW-0dSkZbImrptzGB_q6xsWF_tE=.e43ad528-0709-42b2-8cb6-25ac73770e33@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
 <cRIv9sThIVBKAaKuYW-0dSkZbImrptzGB_q6xsWF_tE=.e43ad528-0709-42b2-8cb6-25ac73770e33@github.com>
Message-ID: <saoGRG9Scg-Uf0o0bjOOEsZCy3anlaR8sAFhWH3s3AU=.eefef753-aa06-4609-a98a-6df4fa55007a@github.com>

On Wed, 19 May 2021 09:19:56 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.
>
> Julia Boes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add bug id to test

Changes requested by michaelm (Reviewer).

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Filter.java line 214:

> 212:      * before the {@code operation} is invoked. More specifically, the response
> 213:      * will typically be sent before the filter {@code operation} is executed.
> 214:      *

I think I'd prefer "may be" rather than "will typically be" here as well. Best not to make any claim about what is more likely to happen.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From jboes at openjdk.java.net  Wed May 19 10:21:02 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 19 May 2021 10:21:02 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods [v3]
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <PkLqbH56PhQs7mXFZ4zdGkaW0rOGAMFXNdzRN47wXHo=.652fbdae-9a6c-43a5-bf41-ac6ccc7c2bc3@github.com>

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.

Julia Boes has updated the pull request incrementally with one additional commit since the last revision:

  address PR comment: change wording

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4085/files
  - new: https://git.openjdk.java.net/jdk/pull/4085/files/8d3749b7..4ea073a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4085&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4085&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4085.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4085/head:pull/4085

PR: https://git.openjdk.java.net/jdk/pull/4085

From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <qVRIEiuc83sNYMxj2s4g08BXRxKhruequuXgyqyRZfs=.43806dd1-0bc5-4c88-b155-f9f4b2ea9ffa@github.com>
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From jboes at openjdk.java.net  Wed May 19 15:31:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Wed, 19 May 2021 15:31:42 GMT
Subject: RFR: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods [v3]
In-Reply-To: <PkLqbH56PhQs7mXFZ4zdGkaW0rOGAMFXNdzRN47wXHo=.652fbdae-9a6c-43a5-bf41-ac6ccc7c2bc3@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
 <PkLqbH56PhQs7mXFZ4zdGkaW0rOGAMFXNdzRN47wXHo=.652fbdae-9a6c-43a5-bf41-ac6ccc7c2bc3@github.com>
Message-ID: <pX86yqLKH1gQvcCwgmNi4rjvPDNdCSy-hJmHW9KIV90=.b9bc2f43-bbf4-479b-8633-10f9f302ee18@github.com>

On Wed, 19 May 2021 10:21:02 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8267379
>
> Julia Boes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address PR comment: change wording

CSR for review: https://bugs.openjdk.java.net/browse/JDK-8267379

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From duke at openjdk.java.net  Wed May 19 15:53:43 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 15:53:43 GMT
Subject: Withdrawn: 8133686: HttpURLConnection.getHeaderFields and
 URLConnection.getRequestProperties methods return field values in reverse
 order
In-Reply-To: <x9RlTgF1mPu2rliFGWWiJMQSaDHahrEdjVUkjRPB3qU=.4d292ec0-b5b8-464f-8394-222d41344ca3@github.com>
References: <x9RlTgF1mPu2rliFGWWiJMQSaDHahrEdjVUkjRPB3qU=.4d292ec0-b5b8-464f-8394-222d41344ca3@github.com>
Message-ID: <2MmGQuEuwnFhq8ZfBXv1cvARA2GYwtydl9fjT3-4dU8=.5ccee3a8-f8bc-4fe9-993e-d4f2b76660ac@github.com>

On Thu, 28 Jan 2021 16:42:02 GMT, Evan Whelan <ewhelan at openjdk.org> wrote:

> Hi all,
> 
> Please review this fix for which corrects the order in which field values are returned from the `HttpURLConnection.getHeaderFields` and `URLConnection.getRequestProperties` methods.
> 
> Currently, the implementation of these methods returns the values in reverse. This does not conform with the RFC2616 spec which outlines that the order of these field values should not be changed. 
> 
> Thanks,
> Evan

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2294

From duke at openjdk.java.net  Wed May 19 16:20:43 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:20:43 GMT
Subject: Withdrawn: JDK-8243376: java.net.SocketPermission.implies(Permission
 p) spec is mismatching with implementation
In-Reply-To: <PpqWVbc0YwPceTDp51hUZGau0nTwmYVkiWdt3Jq5V5o=.b4f002d3-5f64-4654-bb36-6cd929010cec@github.com>
References: <PpqWVbc0YwPceTDp51hUZGau0nTwmYVkiWdt3Jq5V5o=.b4f002d3-5f64-4654-bb36-6cd929010cec@github.com>
Message-ID: <cXQayTaFfFrUHmXKc-wBEbQErDvySSpI1NsfNpa6LKA=.2755c61a-607e-42d2-b599-7f23cea05039@github.com>

On Sat, 2 Jan 2021 10:11:30 GMT, Jayashree S Kumar <github.com+31532647+jaysk1 at openjdk.org> wrote:

> Issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8243376
> 
> Problem
> 
> The scenario is: 
> - Some specified target hostname resolves to two IP addresses (always the same address pair). 
> - The DNS resolved order of the two ip addresses changes (a usual LoadBalancer type behavior). 
> - The CNAME of the two ip addresses differ. 
> 
> In SocketPermission class(void getIP() method), it internally resolves and saves only the first IP address resolved, not all the IP addresses resolved. 
> - Depending on when the implier/implied SocketPermission hostname is resolved, the resolved addresses order differs, and the internally saved IP address mismatches, resulting on SocketPermission#implies() false. 
> 
> 
> Michael McMahon kindly reviewed and suggested changes: https://mail.openjdk.java.net/pipermail/net-dev/2020-May/014001.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1916

From duke at openjdk.java.net  Wed May 19 16:28:44 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:28:44 GMT
Subject: Withdrawn: JDK-8257235: [PATCH] InetAddress.isReachable: Try to use
 an IPPROTO_ICMP socket type before attempting RAW_SOCK
In-Reply-To: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
References: <hbj94d-5j0GvmU1ftg6D4alxZ0DbHcE27RAhS3ORPZg=.7c66b8cb-6536-4bf0-b0e4-cc6f6b911b69@github.com>
Message-ID: <Hl5Kh1-iX1w7BELuNNhoUl6I25rrLxl0JVSWWbbhhTc=.27120260-b970-456e-9dd5-830d848796a2@github.com>

On Sun, 29 Nov 2020 07:54:23 GMT, Jamie Le Tual <github.com+55101029+jamieletual at openjdk.org> wrote:

> Users have been able to send ICMP packets without the need for root privileges or the CAP_NET_RAW capability since at least kernel 3.11.
> 
> For some time now, if the kernel parameter net.ipv4.ping_group_range included the gid of a user sending an icmp packet with the IPPROTO_ICMP protocol, then the packet would>
> It's important to note that the both the checksum and ident field are overwritten by the kernel when this is done.
> 
> Newer distributions are now setting the default value of net.ipv4.ping_group_range to be open to all possible group ids (Fedora 31 and Ubuntu 20.04 for example) so it can b>
> 
> Also of note is the that this is also implemented in MacOS.
> 
> This patch proposes attempting to use IPPROTO_ICMP first, and then fall back to attempting a raw socket and ultimately failing over to tcp echo.
> This patch also alters the logic for identifying icmp reply packets, since the kernel overwrites id ident field when using the IPPROTO_ICMP protocol.
> The method is similar to that used by the ping(8) utility in the iputils package, where we compare data in the icmp_data member of the icmp struct
> to identify the packet as our response. The ping utility compares the timeval, whereas this patch proposes to compare both the timeval and the user's pid.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1502

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <fiq_yIbqC9QRDEcRvYChJl6aWrZvnOxZM4uuDdwYDek=.bbe622b3-b90a-4441-bb0c-ead59bca50d2@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <hfPqSTPSSpxjLndppmuJovqQVW7q2UXmBhzI8sIGDJg=.bdef2a7d-72bd-49ac-b7f6-9ca56ce3cd1e@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
Message-ID: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>

On Wed, 19 May 2021 18:26:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <bm5404KqUHEn19tMHUfAqwRYV2P4thP5SkToARrWwio=.63408fce-7c27-4f06-be58-0fee5ff88f3f@github.com>
Message-ID: <P1n8uhHy1IqLsvr2AH5wQb1wuBkGPofCg2TFvelA4sQ=.1cbb03a5-084d-4548-be7c-fa66b9968f87@github.com>

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <faOe6m8bn6J0ZmXT2mXeQnXapiwOqEixCz4qYhAXRSk=.ec7435aa-b851-4be2-88d2-f122f3fea099@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>

On Wed, 19 May 2021 19:31:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
Message-ID: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
Message-ID: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>

On Wed, 19 May 2021 23:50:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
Message-ID: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD_jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>

On Thu, 20 May 2021 04:05:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 06:45:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 06:45:43 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <PDasfSkiwzPLgDjd0iDukMexFfaazUQmn_5ULXgRimo=.08ff89fc-d740-4a18-8985-07a0d5837e67@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Any more comments?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589

From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
Message-ID: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>

On Thu, 20 May 2021 04:22:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From jboes at openjdk.java.net  Thu May 20 09:36:37 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 20 May 2021 09:36:37 GMT
Subject: Integrated: 8267262: com/sun/net/httpserver/Filter improve API
 documentation of static methods
In-Reply-To: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
References: <HrYJFU2bJ-_GO12rhAgaFOFgwUdG7bX8ph2Tkq1ycgk=.1cadeb3d-3179-4b17-9046-7f37e5433323@github.com>
Message-ID: <BTSlBsMMjtU-Ph0ta6s_vvzLsQJ4ti7ce-34vmPHnqE=.a05357d1-7ffb-4e5f-8567-a7b223b813c3@github.com>

On Tue, 18 May 2021 09:34:25 GMT, Julia Boes <jboes at openjdk.org> wrote:

> The filter operation `Consumer` that is passed to the factory methods can throw an unchecked exception. This change adds a note on the exception handling in that case. It also adds a clarification to `Filter::afterHandler` on the relation of the filter operation and the client receiving the response.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8267379

This pull request has now been integrated.

Changeset: 31320c34
Author:    Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/31320c3474a6054a367e764c2a9fef46ac638998
Stats:     50 lines in 2 files changed: 45 ins; 1 del; 4 mod

8267262: com/sun/net/httpserver/Filter improve API documentation of static methods

Reviewed-by: dfuchs, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/4085

From redestad at openjdk.java.net  Thu May 20 10:45:37 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 20 May 2021 10:45:37 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <fDg1qOMOmwxlR_HRlpvx8j1azbql1-ZwmLcCcZBim6Q=.97f3388f-76cd-4d4c-9e10-755e304be1b9@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:07:34 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:07:34 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <fDg1qOMOmwxlR_HRlpvx8j1azbql1-ZwmLcCcZBim6Q=.97f3388f-76cd-4d4c-9e10-755e304be1b9@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
 <fDg1qOMOmwxlR_HRlpvx8j1azbql1-ZwmLcCcZBim6Q=.97f3388f-76cd-4d4c-9e10-755e304be1b9@github.com>
Message-ID: <-6K32RgKOwmXJztestBAA8OWC406eWVuqTRIjvfzcoQ=.59f5b0be-a1d9-48a8-89bd-5b7c51222bd7@github.com>

On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> Marked as reviewed by redestad (Reviewer).

@cl4es now you can sponsor :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589

From github.com+1324414+desruisseaux at openjdk.java.net  Thu May 20 13:18:36 2021
From: github.com+1324414+desruisseaux at openjdk.java.net (Martin Desruisseaux)
Date: Thu, 20 May 2021 13:18:36 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
 <HdUEpTOskcSrGVzPdKc7P25CVANuuz7ggUbCR6dXbmY=.61700448-ab3d-413a-b6b9-ecbe01c378ea@github.com>
Message-ID: <abxupgx37u8_uxfNqDPuuy8_-53k1Xm2WBBSM6q9NpQ=.4bd7fb77-d4d9-4a78-8881-bd424e758a29@github.com>

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Just for information there is similar issues in `javax.imageio.metadata.IIOMetadataFormatImpl` class in the `java.desktop` module.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589

From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:59:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:59:41 GMT
Subject: Integrated: 8261880: Change nested classes in java.base to static
 nested classes where possible
In-Reply-To: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
References: <mVdZOgJ_puUpdMNfmFgbFEeLPFriBIAjfc2RruOtt8A=.5e449de6-fb08-43d2-82b0-81ca746462b6@github.com>
Message-ID: <Lw3FPs0I3TEN2jP-FgtSuyoZrmwmR5S1-5ApElfeukA=.c5e36212-92c5-4da3-9657-3c09e1be2d12@github.com>

On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

This pull request has now been integrated.

Changeset: 9425d3de
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9425d3de83fe8f4caddef03ffa3f4dd4de58f236
Stats:     15 lines in 11 files changed: 0 ins; 0 del; 15 mod

8261880: Change nested classes in java.base to static nested classes where possible

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589

From moataz.nasser20 at gmail.com  Thu May 20 14:58:01 2021
From: moataz.nasser20 at gmail.com (Moataz Abdelnasser)
Date: Thu, 20 May 2021 16:58:01 +0200
Subject: Accessing 'system' header fields implicitly added by HttpClient
Message-ID: <CAF_Y3GCy989zfWHr-CH7PTC-a2PssLG75TUSzxKzi2+9s-Pt=Q@mail.gmail.com>

Hi!

I've recently released an HTTP cache
(https://mizosoft.github.io/methanol/caching) that operates as part of
an interceptor chain built atop a standard HttpClient.
Currently, the cache can store only one response per request. However,
request headers can specify multiple response variants if nominated by
the 'Vary' header
(e.g. gzip & deflate variants if varying on Accept-Encoding). To
ensure a response is selected only if it is the corrected variant,
incoming requests' Vary-nominated fields
must match against those in the initiating request.

The bummer is that HttpClient can augment requests with implicit
header fields (e.g. Cookie, Authorization, etc.), and accessing these
seems to be impossible (tested that
with 'response.request().headers()', please correct me if I'm wrong).
The cache has to render a response uncacheable if it decides it varies
on these fields, as their values cannot be
known in the initiating request, so they can't be matched against when
new requests are made. It'd be nice if one could access these headers,
maybe via 'response.request().headers()',
or something like 'response.networkRequest().headers()'. This would
increase cache's efficiency. Additionally, I can find it useful for
debugging as it's always good to know what
modifications the client makes to requests.

Regards,
Moataz

From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 21 01:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 01:58:47 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
Message-ID: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
  Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From daniel.fuchs at oracle.com  Fri May 21 08:47:59 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 21 May 2021 09:47:59 +0100
Subject: Accessing 'system' header fields implicitly added by HttpClient
In-Reply-To: <CAF_Y3GCy989zfWHr-CH7PTC-a2PssLG75TUSzxKzi2+9s-Pt=Q@mail.gmail.com>
References: <CAF_Y3GCy989zfWHr-CH7PTC-a2PssLG75TUSzxKzi2+9s-Pt=Q@mail.gmail.com>
Message-ID: <6368e670-7c02-7f4d-fe53-42d2232e71a9@oracle.com>

Hi Moataz,

This sounds like a reasonable request, with a concrete use case.

I have logged https://bugs.openjdk.java.net/browse/JDK-8267510

best regards,

-- daniel

On 20/05/2021 15:58, Moataz Abdelnasser wrote:
> Hi!
> 
> I've recently released an HTTP cache
> (https://mizosoft.github.io/methanol/caching) that operates as part of
> an interceptor chain built atop a standard HttpClient.
> Currently, the cache can store only one response per request. However,
> request headers can specify multiple response variants if nominated by
> the 'Vary' header
> (e.g. gzip & deflate variants if varying on Accept-Encoding). To
> ensure a response is selected only if it is the corrected variant,
> incoming requests' Vary-nominated fields
> must match against those in the initiating request.
> 
> The bummer is that HttpClient can augment requests with implicit
> header fields (e.g. Cookie, Authorization, etc.), and accessing these
> seems to be impossible (tested that
> with 'response.request().headers()', please correct me if I'm wrong).
> The cache has to render a response uncacheable if it decides it varies
> on these fields, as their values cannot be
> known in the initiating request, so they can't be matched against when
> new requests are made. It'd be nice if one could access these headers,
> maybe via 'response.request().headers()',
> or something like 'response.networkRequest().headers()'. This would
> increase cache's efficiency. Additionally, I can find it useful for
> debugging as it's always good to know what
> modifications the client makes to requests.
> 
> Regards,
> Moataz
> 


From weijun at openjdk.java.net  Fri May 21 14:00:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 14:00:39 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  typo on windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+10835776+stsypanov at openjdk.java.net  Fri May 21 14:04:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 21 May 2021 14:04:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

Hi guys, any more comments here? Please ping me if I've missed something

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From dfuchs at openjdk.java.net  Fri May 21 14:26:48 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 14:26:48 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?

I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:

> 153:      */
> 154:     public List<String> get(String fileName) {
> 155:         ArrayList<String> jarFiles;

This could probably be declared as:


List<String> jarFiles;

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:

> 262:                 String jar = jarFiles[i];
> 263:                 bw.write(jar + "\n");
> 264:                 ArrayList<String> jarlist = jarMap.get(jar);

Here again, jarList could probably be declared as `List<String>`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Fri May 21 14:26:50 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 14:26:50 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <49DKqYCEGnU3_LyaAoKbyyCrNWeOhpyi06nqfNwqtu0=.3de3c091-0eb1-4d37-881c-f532a6a2e120@github.com>
Message-ID: <7M39TjBM4Y3jcrY8TSkasy25HcSB8WqKOVu_JK5c4mU=.122ac5e0-50e5-4bf6-80ae-e32337c6938d@github.com>

On Fri, 21 May 2021 13:13:04 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hi guys, any more comments here? Please ping me if I've missed something

I suspect this will require renaming some fields and changing comments, e.g. requestList is no longer a good name for the field in AbstractPoller, its comments need changes too. The field in ResolverConfigurationImpl is searchList, it will require a few changes. There may be more, I just picked out a few.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 14:55:16 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 14:55:16 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:

> 152:      * @param fileName the key of the mapping
> 153:      */
> 154:     public List<String> get(String fileName) {

IcedTea-Web seems to be using this method reflectively:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Fri May 21 15:02:57 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 15:02:57 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
Message-ID: <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>

On Fri, 21 May 2021 14:52:21 GMT, Thiago Henrique H?pner <github.com+13357965+Thihup at openjdk.org> wrote:

> IcedTea-Web seems to be using this method reflectively:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80

I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+13357965+thihup at openjdk.java.net  Fri May 21 15:15:15 2021
From: github.com+13357965+thihup at openjdk.java.net (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Fri, 21 May 2021 15:15:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
 <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
Message-ID: <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>

On Fri, 21 May 2021 15:00:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 154:
>> 
>>> 152:      * @param fileName the key of the mapping
>>> 153:      */
>>> 154:     public List<String> get(String fileName) {
>> 
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>
>> IcedTea-Web seems to be using this method reflectively:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
> 
> I assume this doesn't work with JDK 16, at least not without using --add-options to export jdk.internal.util.jar.

Just for completeness, they're using the add-exports:
https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From dfuchs at openjdk.java.net  Fri May 21 15:55:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:55:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
Message-ID: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo on windows

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:

> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
> 120:                     }

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:

> 548:      * @throws IOException if the connection was unsuccessful.
> 549:      */
> 550:     @SuppressWarnings("removal")

Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921:

> 919:     }
> 920: 
> 921:     @SuppressWarnings("removal")

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...


            PrivilegedAction<Socket> pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From alanb at openjdk.java.net  Fri May 21 17:03:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 21 May 2021 17:03:12 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
Message-ID: <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>

On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition duri
 ng heavy loads and where a significant number of ephemeral ports are being allocated.
> 
> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.

test/jdk/java/net/Socket/UdpSocket.java line 151:

> 149:             }
> 150:         }
> 151:         return newUdpSocket;

I added this test in advance of JEP 353 as we didn't have much coverage for this deprecated constructor. No objection to the retry if it helps.  Is the catching of SocketException a left over from testing? I assume the patch can be simplified down to:


try {
   return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
} catch (BindException e) {
    System.out.println(...);
   return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From msheppar at openjdk.java.net  Fri May 21 17:03:12 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Fri, 21 May 2021 17:03:12 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
Message-ID: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>

The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition during
  heavy loads and where a significant number of ephemeral ports are being allocated.

As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.

-------------

Commit messages:
 - JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
 - JDK-8265362: additions to execute a retry of UDP Socket construction if a BindException thrown during the testMaxSockets test

Changes: https://git.openjdk.java.net/jdk/pull/4103/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4103&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265362
  Stats: 14 lines in 2 files changed: 10 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4103.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4103/head:pull/4103

PR: https://git.openjdk.java.net/jdk/pull/4103

From msheppar at openjdk.java.net  Fri May 21 17:03:13 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Fri, 21 May 2021 17:03:13 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
Message-ID: <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>

On Wed, 19 May 2021 05:56:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition dur
 ing heavy loads and where a significant number of ephemeral ports are being allocated.
>> 
>> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.
>
> test/jdk/java/net/Socket/UdpSocket.java line 151:
> 
>> 149:             }
>> 150:         }
>> 151:         return newUdpSocket;
> 
> I added this test in advance of JEP 353 as we didn't have much coverage for this deprecated constructor. No objection to the retry if it helps.  Is the catching of SocketException a left over from testing? I assume the patch can be simplified down to:
> 
> 
> try {
>    return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
> } catch (BindException e) {
>     System.out.println(...);
>    return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
> }

yes, thanks for that  ... updated as requested

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From dfuchs at openjdk.java.net  Fri May 21 17:12:55 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 17:12:55 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
Message-ID: <LFvn9IEGIrEoTcVdjVY3vU1aEdJI-JpiSvgEmX3zuv0=.4161a963-b43c-4e88-9bdd-7adb07f10522@github.com>

On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition duri
 ng heavy loads and where a significant number of ephemeral ports are being allocated.
> 
> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.

Thanks for taking this on Mark! The proposed changes look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4103

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
Message-ID: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 <SKbpAXV2MyA6RXDlsJ1lek6KUcW_KyzDpilfvfC0yR8=.8ad77721-20a5-4860-8c4b-c43e4d79cd9e@github.com>
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: <UgO9-C6Oo_ulIRbQWW6Jw5HEPeJHSAnpgfdXEfiQVNE=.bf8a2656-e9bf-4627-a37b-cc9ca84e6d1b@github.com>

On Fri, 21 May 2021 18:26:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <J7PKD_tgpaSH7oobcuRkh3qKFsr1wAPbxqEPaW7dJa0=.71e1df8c-8f2d-49b0-8a21-819907087678@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Fri May 21 20:18:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:18:58 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
 <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com>

On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
> 
>> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
>> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
>> 120:                     }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:23:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:23:14 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <CYdb_wI7I2jN5d17ZTDTHbXSrTlcEiGLxlqL-LHQ8L0=.fd0b144a-1ef2-45a5-a4ec-aff71641beb6@github.com>
 <k2upNbKWXhuQFxL1hiEcjhDvV6KqILwRmeOKql6o0ZI=.3298dccc-d994-427e-b299-84e95082cc0d@github.com>
Message-ID: <TnTeR-4Xk7slDLMBTPuFzsj8BIppB92tZ1OwEBEylEw=.850cff28-f809-4c23-ad67-6c1e19977d30@github.com>

On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
> 
>> 548:      * @throws IOException if the connection was unsuccessful.
>> 549:      */
>> 550:     @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 21 20:37:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:37:30 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
Message-ID: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update FtpClient.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
Message-ID: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <F2m2r-L3GvRtUkGL7y2Xp5ZZLId4y0VXjvj-rcAKvMo=.e211614f-a584-47d6-af60-62427fddd295@github.com>
Message-ID: <S-kozOfLwraS98p1UoWwwNGs-M6kfUYjtcFVwtnFChY=.13224ab0-59c6-42b9-be32-46d2599b7acf@github.com>

On Fri, 21 May 2021 20:43:05 GMT, Phil Race <prr at openjdk.org> wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From mcimadamore at openjdk.java.net  Fri May 21 23:20:04 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 21 May 2021 23:20:04 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
Message-ID: <uZi_9js7-Pn8HL5gvQyIcYCQNg6GYMAfNgfrwbTFmCM=.d1781f1b-9f50-4c8a-8cbb-9c4a03ae025e@github.com>

On Fri, 21 May 2021 14:22:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?
> 
> I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.

I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.

And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Sat May 22 06:49:00 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 06:49:00 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
 <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>
Message-ID: <-kanvMy2PMV0UdjoQA76tGzQ-uPWlYvNr09u7Iw-LPw=.8948d9f6-4703-4c01-a3fd-ef9301cea0b8@github.com>

On Fri, 21 May 2021 17:00:11 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> test/jdk/java/net/Socket/UdpSocket.java line 151:
>> 
>>> 149:             }
>>> 150:         }
>>> 151:         return newUdpSocket;
>> 
>> I added this test in advance of JEP 353 as we didn't have much coverage for this deprecated constructor. No objection to the retry if it helps.  Is the catching of SocketException a left over from testing? I assume the patch can be simplified down to:
>> 
>> 
>> try {
>>    return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
>> } catch (BindException e) {
>>     System.out.println(...);
>>    return new Socket(InetAddress.getLoopbackAddress(), 8000, false);
>> }
>
> yes, thanks for that  ... updated as requested

Thanks, and if you want to keep it consistent with the existing code then you could rename "Socket newUdpSocket" and "biEx", or just change it to "return new Socket(...)".

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From alanb at openjdk.java.net  Sat May 22 06:49:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 06:49:01 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <-kanvMy2PMV0UdjoQA76tGzQ-uPWlYvNr09u7Iw-LPw=.8948d9f6-4703-4c01-a3fd-ef9301cea0b8@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
 <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>
 <-kanvMy2PMV0UdjoQA76tGzQ-uPWlYvNr09u7Iw-LPw=.8948d9f6-4703-4c01-a3fd-ef9301cea0b8@github.com>
Message-ID: <Ld2QoXE5hOFQU5pL3O1krVmGdnFfgB4BYTUsHhhpc54=.29ecaeba-2605-4914-bf46-1bd3c77f3cf2@github.com>

On Sat, 22 May 2021 06:45:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> yes, thanks for that  ... updated as requested
>
> Thanks, and if you want to keep it consistent with the existing code then you could rename "Socket newUdpSocket" and "biEx", or just change it to "return new Socket(...)".

BTW: Is one retry enough? There is at least one other replace where we've had to retry to workaround a macOS bug and one retry was enough there too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <smL9ZKyiXA3fpK2rMeP2lu6pKGHF5RI0vXD5ZuzHE0w=.c30d4225-547a-41ee-a1e6-3ae0fb1a3701@github.com>
 <jGowvXeBYEbVEQC3_9eb6sGpQS9HgXNKYh6BNUm_pWo=.693dc4cd-b30e-4a14-b10f-59d13d83ad66@github.com>
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 <JgXbTV4Gky1PFnEaYjCaAWq7XEDunGWGzrsZZ29OToI=.f4b067e6-9ef7-4257-84c9-dd9811cab1e5@github.com>
 <ay65MymeIiwqWtuLEOopxvD3g1mnQbIkq6q-0gvTvUo=.acd1fc9a-78a0-46ae-8b00-46ed0928dad5@github.com>
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 <Vnln0zztkV5pg_RDj-g5KV8PszWwg38L8JqES_RHbUs=.6a87f954-a6e6-4594-8912-991be370061a@github.com>
 <nA-UT6VG8qvf5x8NLLsuV3ZzEi8WiON221SZ2Iz4lGI=.d3c616e5-a0e5-4a3b-9cef-f9f4c7901e32@github.com>
 <UlMV4QfrDNF36hZrHHGJhvGM-Z8aKp7cchD
 _jeihXL0=.1275ead4-d3a9-464c-8397-ef31d58e4529@github.com>
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 <QQS7811s9B68gLQQyVOFlG3V39KzKbWPEYZAQqBNBrs=.34a092eb-ca26-4533-82b1-696ca469121c@github.com>
 <IPy-Xg1v6HxhL_fE6ZL3UaxBtnG-ZQCTk7M0-kvQCv4=.b44f688d-3c84-42a1-a4ab-f16fbb194a3c@github.com>
 <eEp3RKNQ2piSg6B2jrh3-5GqD1BHbF5SXLXr46mJgx4=.3367ee9a-2432-4cf2-8512-9dbb819c0dd6@github.com>
Message-ID: <EY0wxSpTN5BT63blVVvIHQ69tvBmgDTXcSroIDhlhcA=.2e93e74b-33e5-444e-8bcb-c8ffc3621597@github.com>

On Fri, 21 May 2021 18:00:13 GMT, Phil Race <prr at openjdk.org> wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From msheppar at openjdk.java.net  Sat May 22 10:56:59 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Sat, 22 May 2021 10:56:59 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <Ld2QoXE5hOFQU5pL3O1krVmGdnFfgB4BYTUsHhhpc54=.29ecaeba-2605-4914-bf46-1bd3c77f3cf2@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
 <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>
 <-kanvMy2PMV0UdjoQA76tGzQ-uPWlYvNr09u7Iw-LPw=.8948d9f6-4703-4c01-a3fd-ef9301cea0b8@github.com>
 <Ld2QoXE5hOFQU5pL3O1krVmGdnFfgB4BYTUsHhhpc54=.29ecaeba-2605-4914-bf46-1bd3c77f3cf2@github.com>
Message-ID: <UwFPkEQ7hjlJx8Qe97s_xu5KSZNo0EDoHwyLSGaIrr4=.fcea6693-aab9-47c4-bf2b-43a4dc19ebae@github.com>

On Sat, 22 May 2021 06:46:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks, and if you want to keep it consistent with the existing code then you could rename "Socket newUdpSocket" and "biEx", or just change it to "return new Socket(...)".
>
> BTW: Is one retry enough? There is at least one other replace where we've had to retry to workaround a macOS bug and one retry was enough there too.

I have submitted a significant number of MACH5 job runs with repeat mode over the past week - approx  50 x 50,  and observed the retry to have been triggered about 5 times, this gives some level of assurance that test stability will exist. But CI builds will exercise this a lot more.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
Message-ID: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:04:05 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:04:05 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
Message-ID: <IoWDwUmPubODIP01IFaA2LU7OOQOAJbLOFUCSCPeduU=.5a988da4-2688-4564-8bd8-0ec80c3c85a3@github.com>

On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 155:
> 
>> 153:      */
>> 154:     public List<String> get(String fileName) {
>> 155:         ArrayList<String> jarFiles;
> 
> This could probably be declared as:
> 
> 
> List<String> jarFiles;

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:10:40 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:10:40 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
Message-ID: <D-7LT5FenEeQBa66sxoJ1GjYHIEF9vVsLrx9E8WJsL4=.33f7770f-02fe-4853-ad66-31ab8530052a@github.com>

On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/jar/JarIndex.java line 264:
> 
>> 262:                 String jar = jarFiles[i];
>> 263:                 bw.write(jar + "\n");
>> 264:                 ArrayList<String> jarlist = jarMap.get(jar);
> 
> Here again, jarList could probably be declared as `List<String>`

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 07:17:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 07:17:08 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
 <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
 <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>
Message-ID: <UuB66XL3XBdCyrC0dQNfgqdXn_-y7x5UBCpCFVLV_ts=.5733e12c-036c-4561-92b8-4f74d596fddd@github.com>

On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique H?pner <github.com+13357965+Thihup at openjdk.org> wrote:

>>> IcedTea-Web seems to be using this method reflectively:
>>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>> 
>> I assume this doesn't work with JDK 16, at least not without using --add-exports to export jdk.internal.util.jar.
>
> Just for completeness, they're using the add-exports:
> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19

Should we then revert the changes to `JarIndex`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From dfuchs at openjdk.java.net  Mon May 24 09:03:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 09:03:10 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4138

From github.com+7806504+liach at openjdk.java.net  Mon May 24 09:28:15 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 09:28:15 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <UuB66XL3XBdCyrC0dQNfgqdXn_-y7x5UBCpCFVLV_ts=.5733e12c-036c-4561-92b8-4f74d596fddd@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
 <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
 <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>
 <UuB66XL3XBdCyrC0dQNfgqdXn_-y7x5UBCpCFVLV_ts=.5733e12c-036c-4561-92b8-4f74d596fddd@github.com>
Message-ID: <TaoJGVNFeFjbiLpzJUgmjxA4Qf4qOBfLwa-y4RI6wcI=.09e1e81b-7308-4cd7-a3c4-86239cd7c1f4@github.com>

On Mon, 24 May 2021 07:13:29 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Just for completeness, they're using the add-exports:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19
>
> Should we then revert the changes to `JarIndex`?

But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Mon May 24 10:17:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 24 May 2021 10:17:19 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <TaoJGVNFeFjbiLpzJUgmjxA4Qf4qOBfLwa-y4RI6wcI=.09e1e81b-7308-4cd7-a3c4-86239cd7c1f4@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
 <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
 <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>
 <UuB66XL3XBdCyrC0dQNfgqdXn_-y7x5UBCpCFVLV_ts=.5733e12c-036c-4561-92b8-4f74d596fddd@github.com>
 <TaoJGVNFeFjbiLpzJUgmjxA4Qf4qOBfLwa-y4RI6wcI=.09e1e81b-7308-4cd7-a3c4-86239cd7c1f4@github.com>
Message-ID: <d_g8u4DwLcZYUKYcCg-hVv0cW8I4w7FgSHLqr0AnJfw=.b0c10c92-6d97-441e-8e85-b4238bca071e@github.com>

On Mon, 24 May 2021 09:25:08 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> Should we then revert the changes to `JarIndex`?
>
> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?

True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+7806504+liach at openjdk.java.net  Mon May 24 12:11:38 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 24 May 2021 12:11:38 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <d_g8u4DwLcZYUKYcCg-hVv0cW8I4w7FgSHLqr0AnJfw=.b0c10c92-6d97-441e-8e85-b4238bca071e@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <zHKLW_fUHhW7ooe0BXSPrtrEhPbQG2sqUUE4cuGTek8=.fb997efe-8efd-4e17-9c2a-c6cedeee073d@github.com>
 <CP4JjOfDK7ZtqFHwPv9QECKvYLlE439FmHrE4H-C_HA=.49a61a6a-68c6-4b23-b676-a261d6ce9667@github.com>
 <nnk5VVBu-NklKbQQoZTXR4D6V64EzX0ovYENcUDulRM=.f60fb53f-fed0-4f57-b310-d085ba8d6f4f@github.com>
 <UuB66XL3XBdCyrC0dQNfgqdXn_-y7x5UBCpCFVLV_ts=.5733e12c-036c-4561-92b8-4f74d596fddd@github.com>
 <TaoJGVNFeFjbiLpzJUgmjxA4Qf4qOBfLwa-y4RI6wcI=.09e1e81b-7308-4cd7-a3c4-86239cd7c1f4@github.com>
 <d_g8u4DwLcZYUKYcCg-hVv0cW8I4w7FgSHLqr0AnJfw=.b0c10c92-6d97-441e-8e85-b4238bca071e@github.com>
Message-ID: <nytCTDq_seGXLrUkiwnaKb7ZMYWkdAYNBhTveU2ZeB4=.2a26d4db-96a8-4197-90a0-a8a473579327@github.com>

On Mon, 24 May 2021 10:13:55 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> But don't people access these internal code at their own risk, as jdk may change these code at any time without notice?
>
> True, I just wonder whether it's OK to change internals when we know for sure that this breaks 3rd party code

I think so. There are always unexpected ways the jdk may break and third-party libraries would need a different workaround for a new java version. For instance, in Apache log4j, its library has a special guard against the broken implementation of Reflection getCallerClass during java 7. The libraries can just handle these in their version-specific components.

Especially given the fact that the code linked above already has version-specific handling (8 vs 9), so it won't hurt much for them to add another piece of logic to handle jdk 17+ in case this optimization is merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From msheppar at openjdk.java.net  Mon May 24 12:30:38 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Mon, 24 May 2021 12:30:38 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
Message-ID: <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>

> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition duri
 ng heavy loads and where a significant number of ephemeral ports are being allocated.
> 
> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.

Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
  update as per request by AB

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4103/files
  - new: https://git.openjdk.java.net/jdk/pull/4103/files/1f05203e..87cd9c5e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4103&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4103&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4103.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4103/head:pull/4103

PR: https://git.openjdk.java.net/jdk/pull/4103

From msheppar at openjdk.java.net  Mon May 24 12:30:39 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Mon, 24 May 2021 12:30:39 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <UwFPkEQ7hjlJx8Qe97s_xu5KSZNo0EDoHwyLSGaIrr4=.fcea6693-aab9-47c4-bf2b-43a4dc19ebae@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <TqBgS8fwUgJk0guc2ZYjDy7e6-2mET8UYAkIDooy4a8=.2df11eca-e464-48a6-8184-cdb9bb01c665@github.com>
 <IuzqNxknGCf6-ghzgHqklxKgTOG3qpkN5cqhp3fF4U8=.7f39e67b-6e6b-4734-92d7-b4d2a6fcdf3b@github.com>
 <-kanvMy2PMV0UdjoQA76tGzQ-uPWlYvNr09u7Iw-LPw=.8948d9f6-4703-4c01-a3fd-ef9301cea0b8@github.com>
 <Ld2QoXE5hOFQU5pL3O1krVmGdnFfgB4BYTUsHhhpc54=.29ecaeba-2605-4914-bf46-1bd3c77f3cf2@github.com>
 <UwFPkEQ7hjlJx8Qe97s_xu5KSZNo0EDoHwyLSGaIrr4=.fcea6693-aab9-47c4-bf2b-43a4dc19ebae@github.com>
Message-ID: <tQpYd08YXSYQpdAMy2lYE48vqI7X3cV8XZKCmAde1t8=.4c247f96-8058-4385-b2af-2b22fefe8a61@github.com>

On Sat, 22 May 2021 10:54:06 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> BTW: Is one retry enough? There is at least one other replace where we've had to retry to workaround a macOS bug and one retry was enough there too.
>
> I have submitted a significant number of MACH5 job runs with repeat mode over the past week - approx  50 x 50,  and observed the retry to have been triggered about 5 times, this gives some level of assurance that test stability will exist. But CI builds will exercise this a lot more.

updated as requested newUdpSocket --> s, and biEx --> unexpected

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <frlgb84xuNLK7qJyOO0Si7X1EigRoOHvS6MaAUhFdXw=.9d99bd48-1bbb-450d-ae35-5082691b1c88@github.com>
 <wT2h7CBtL5bieX1MK2OT4nr2TMtWx7Z13gRDZN3Iwzo=.5eb66fee-77b3-46ac-93d1-b896030d7af7@github.com>
 <bgLNnRc1DiMH7_idcLwtDYvWYDFtMjBQfPgi3UrtAB8=.0b2beada-d2bf-4a1b-a43b-1f26423db1a0@github.com>
Message-ID: <lPk0z6baFFN6QyO0FyiIGkTu9xxIRjx0mu2IET_Kl30=.94dea9d7-9715-41c9-8069-91b5b91a6390@github.com>

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From github.com+579573+zoulasc at openjdk.java.net  Mon May 24 14:03:11 2021
From: github.com+579573+zoulasc at openjdk.java.net (zoulasc)
Date: Mon, 24 May 2021 14:03:11 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
Message-ID: <RnjG0BNXIjcT1KwQ08usl8bGlJT7ahF5ngME1aIsYqM=.2bcff4b4-5a6e-4cff-8117-c10ef928d90a@github.com>

On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition dur
 ing heavy loads and where a significant number of ephemeral ports are being allocated.
>> 
>> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.
>
> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
>   update as per request by AB

Changes requested by zoulasc at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <ErcuQXTihK3DvF1qE6VRicIPIaRHK9upkv59SGzW_PA=.b5fbb915-d64e-42bc-b0ff-a02766c6ba9f@github.com>

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang 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 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071

From msheppar at openjdk.java.net  Mon May 24 14:39:24 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Mon, 24 May 2021 14:39:24 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
Message-ID: <yc80eyLefzNpzUH2fIRP0jeOJ3svOYWfZ5YAsUiEv_U=.68f6adba-9257-4d75-92fe-3eb47759c548@github.com>

On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition dur
 ing heavy loads and where a significant number of ephemeral ports are being allocated.
>> 
>> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.
>
> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
>   update as per request by AB

I used stdout for convenience as it aligns with the  two other output statements, so that I see immediately the retry output as follows:

----------System.out:(12/349)----------
[TestNG] Running:
  java/net/Socket/UdpSocket.java

BindException caught retry Socket creation
test UdpSocket.testMaxSockets(): success
test UdpSocket.testSendReceive(): success

===============================================

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From msheppar at openjdk.java.net  Mon May 24 14:39:24 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Mon, 24 May 2021 14:39:24 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <yc80eyLefzNpzUH2fIRP0jeOJ3svOYWfZ5YAsUiEv_U=.68f6adba-9257-4d75-92fe-3eb47759c548@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
 <yc80eyLefzNpzUH2fIRP0jeOJ3svOYWfZ5YAsUiEv_U=.68f6adba-9257-4d75-92fe-3eb47759c548@github.com>
Message-ID: <rrIDQi8rdi6zMewiGpgzhE1gmz4VbKUNnFTn6Lls59o=.aecb0875-415f-420c-a3e1-2979d6233b86@github.com>

On Mon, 24 May 2021 14:34:54 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
>>   update as per request by AB
>
> I used stdout for convenience as it aligns with the  two other output statements, so that I see immediately the retry output as follows:
> 
> ----------System.out:(12/349)----------
> [TestNG] Running:
>   java/net/Socket/UdpSocket.java
> 
> BindException caught retry Socket creation
> test UdpSocket.testMaxSockets(): success
> test UdpSocket.testSendReceive(): success
> 
> ===============================================

I could have used return directly in multiple places ... but my style preference is a single exit point from a method

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From alanb at openjdk.java.net  Mon May 24 14:52:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 24 May 2021 14:52:08 GMT
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
Message-ID: <jZ0HhJUDBr-ndlhEdnf23tmVaeuIeypjASytvYriqoo=.83441b5c-8699-478e-bb44-a187bb4c6978@github.com>

On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition dur
 ing heavy loads and where a significant number of ephemeral ports are being allocated.
>> 
>> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.
>
> Mark Sheppard has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8265362 java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)
>   update as per request by AB

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From christos at zoulas.com  Mon May 24 14:58:05 2021
From: christos at zoulas.com (Christos Zoulas)
Date: Mon, 24 May 2021 10:58:05 -0400
Subject: RFR: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64) [v2]
In-Reply-To: <rrIDQi8rdi6zMewiGpgzhE1gmz4VbKUNnFTn6Lls59o=.aecb0875-415f-420c-a3e1-2979d6233b86@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
 <4VMn4viExIFvApPHqTFj9xWpUJYnMKyNij22oePZkPY=.5759aa8a-7a75-4d05-9295-7b5ec0020929@github.com>
 <yc80eyLefzNpzUH2fIRP0jeOJ3svOYWfZ5YAsUiEv_U=.68f6adba-9257-4d75-92fe-3eb47759c548@github.com>
 <rrIDQi8rdi6zMewiGpgzhE1gmz4VbKUNnFTn6Lls59o=.aecb0875-415f-420c-a3e1-2979d6233b86@github.com>
Message-ID: <45DD47E0-CEF9-4E8C-8ECF-18FE52A80EEE@zoulas.com>



> On May 24, 2021, at 10:39 AM, Mark Sheppard <msheppar at openjdk.java.net> wrote:
> 
> I could have used return directly in multiple places ... but my style preference is a single exit point from a method

My preference is the opposite :-) I like the "early returns" coding style because I don't need to "keep state" while
reviewing code; specially long methods (my brain is not as good as it used to be). In this case there is also over
initialization of "s", (it does not need to be set to null), and because of the java flow control analysis deficiencies
"s" cannot be declared to  be "final".  So getting rid of the variable makes a lot of sense to me (fewer lines of code
and less complexity).

Best,

christos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210524/75a4925d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20210524/75a4925d/signature.asc>

From ewhelan at openjdk.java.net  Mon May 24 15:08:50 2021
From: ewhelan at openjdk.java.net (Evan Whelan)
Date: Mon, 24 May 2021 15:08:50 GMT
Subject: RFR: 8133686: HttpURLConnection.getHeaderFields and
 URLConnection.getRequestProperties methods return field values in reverse
 order [v3]
In-Reply-To: <x9RlTgF1mPu2rliFGWWiJMQSaDHahrEdjVUkjRPB3qU=.4d292ec0-b5b8-464f-8394-222d41344ca3@github.com>
References: <x9RlTgF1mPu2rliFGWWiJMQSaDHahrEdjVUkjRPB3qU=.4d292ec0-b5b8-464f-8394-222d41344ca3@github.com>
Message-ID: <hKWNNyVFyXnbxI5R-R8JfMWBa6utBKbMxPwOhQqOK2w=.3a65ad96-f57d-4283-8068-0c568293fc2a@github.com>

> Hi all,
> 
> Please review this fix for which corrects the order in which field values are returned from the `HttpURLConnection.getHeaderFields` and `URLConnection.getRequestProperties` methods.
> 
> Currently, the implementation of these methods returns the values in reverse. This does not conform with the RFC2616 spec which outlines that the order of these field values should not be changed. 
> 
> Thanks,
> Evan

Evan Whelan has updated the pull request incrementally with one additional commit since the last revision:

  MessageHeaderTest add comma to copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2294/files
  - new: https://git.openjdk.java.net/jdk/pull/2294/files/1a74ae6e..4e0c96cb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2294&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2294&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2294/head:pull/2294

PR: https://git.openjdk.java.net/jdk/pull/2294

From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071

From weijun at openjdk.java.net  Mon May 24 21:51:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 21:51:32 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <uZFOdkIRuHXdV9eeHK7gxVahxBm7-rwv3G8AyFXXh8k=.73f7b82b-95ea-4dea-a8c8-b748207a76d0@github.com>
Message-ID: <Z9cjMOMOHf9x-s6etCh2UndHcYFdv8xDkoEsCkRxM1s=.6bfb5a77-5987-45db-a0ce-bd150b328a4f@github.com>

On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From msheppar at openjdk.java.net  Mon May 24 22:09:53 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Mon, 24 May 2021 22:09:53 GMT
Subject: Integrated: JDK-8265362 java/net/Socket/UdpSocket.java fails with
 "java.net.BindException: Address already in use" (macos-aarch64)
In-Reply-To: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
References: <uWu91uwOj_Bo4qz2QqtVQWXaw_76S6OgBiQs4yYbSLw=.e1d0361c-141c-43c3-8757-5ca9d8fa7d8f@github.com>
Message-ID: <grtVFs0s3q3CMlYSL5_UaHp4SzWAWAEm_Ilvr8VclMU=.503b9031-b9e3-4fa2-9f9b-1b1da304ca42@github.com>

On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> The test java/net/Socket/UdpSocket.java has been seen to fail with a BindException, in the testMaxSockets test, on a regular basis on macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP Sockets that may be created as defined by a system property sun.net.maxDatagramSockets. It invokes the Socket constructor Socket(InetAddress host, int port, boolean stream) with stream set to false to create a UDP Socket. This instantiation is a compound operation, consisting of the creation of a socket, the explicit binding of wildcard address and ephemeral port, and a connect to the socket end point specified in the constructor parameters.  Analysis has shown that during the test that the OS intermittently allocates the same ephemeral port multiple times during the bind system call, such that two separate sockets end up bound to the same port. Then on the connect invocation a BindException is thrown for the second socket. This has been determined to be a transient condition duri
 ng heavy loads and where a significant number of ephemeral ports are being allocated.
> 
> As this is deemed an OS issues, and in order to increase test stability, it has been found that for the BindException condition a retry of the Socket creation mitigates the issues and tests the max creation property.

This pull request has now been integrated.

Changeset: bb085f68
Author:    Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb085f684d1154ffd6b2169259c67cfb19958380
Stats:     14 lines in 2 files changed: 10 ins; 3 del; 1 mod

8265362: java/net/Socket/UdpSocket.java fails with "java.net.BindException: Address already in use" (macos-aarch64)

Reviewed-by: dfuchs, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4103

From jpai at openjdk.java.net  Tue May 25 04:46:56 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 04:46:56 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in switch
 statement
Message-ID: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>

Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?

I've run `make docs-image` locally and the generated javadoc after this change looks fine.

-------------

Commit messages:
 - 8255674 SSLEngine class description is missing "case" in switch statement

Changes: https://git.openjdk.java.net/jdk/pull/4180/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4180&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255674
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4180.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4180/head:pull/4180

PR: https://git.openjdk.java.net/jdk/pull/4180

From xuelei at openjdk.java.net  Tue May 25 04:59:12 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 25 May 2021 04:59:12 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: <3oufWYMQuqhlFivO8BxbkU9uDFpCxIQYl6XIkhkXvU0=.dc673a0f-2553-4905-94aa-caebd640b041@github.com>

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180

From jpai at openjdk.java.net  Tue May 25 07:44:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 07:44:09 GMT
Subject: Integrated: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: <xrPRupVV8_Q6IRV6J-WddcnLtochxK_vpxGK3S-jT-4=.deaa6f93-ff9b-4279-ad29-9cadefa9232a@github.com>

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

This pull request has now been integrated.

Changeset: 0a03fc84
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a03fc84b3289cf8c8effca7324f71146270a8e2
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8255674: SSLEngine class description is missing "case" in switch statement

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180

From jpai at openjdk.java.net  Tue May 25 07:44:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 07:44:08 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: <hDxuDcNePUAJa-TREAwDGpCMeAiT0dYco0mJcLAmhqA=.476dbe43-6cd3-4817-b62a-fa8f5f1ec863@github.com>

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

Thank you Xuelei for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 07:45:32 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 07:45:32 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v2]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <SeuJn6j3BvEloOM2SEd8qvOWL0blZB7c31ej5NmLlpQ=.377f4d1b-6ed1-491d-bb78-ebc1b7b7e62b@github.com>

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

?????? ??????? has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains three new commits since the last revision:

 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/73029fe1..158006c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00-01

  Stats: 17 lines in 2 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 11:42:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 11:42:41 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v2]
In-Reply-To: <uZi_9js7-Pn8HL5gvQyIcYCQNg6GYMAfNgfrwbTFmCM=.d1781f1b-9f50-4c8a-8cbb-9c4a03ae025e@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <YCatUyZhL5cQFfGE3btkw9JhE4U5E1deyBY0A7fsZOs=.29ab9705-a052-4e1e-a484-c4098c8df81f@github.com>
 <uZi_9js7-Pn8HL5gvQyIcYCQNg6GYMAfNgfrwbTFmCM=.d1781f1b-9f50-4c8a-8cbb-9c4a03ae025e@github.com>
Message-ID: <SST5WQa2bhNkOptUZ37uDKPjYjCsl3-hXiBQ3h6G0vQ=.d5ed9288-75eb-4c7b-bd2c-ef35478bfd45@github.com>

On Fri, 21 May 2021 23:16:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I don't remember all the comments you have received in this thread but have you verified that arbitrarily changing `LinkedList` into `ArrayList` in these classes is not going to significantly increase the footprint in the case where lists are empty or contain only one or two elements?
>> 
>> I am not convinced that a global replacement of  `LinkedList` by `ArrayList` is necessarily good - even though I agree that `ArrayList` is generally more efficient.
>
> I second the footprint concerns from @dfuch. I've seen with first hand cases where widespread uses of array lists for holding 1-2-3 elements (e.g. think of a graph where each node might only have a very small number of outgoing edges) lead to massive memory over-utilization. If the average size is known, at the very least I'd argue to replace with an array list which is sized correctly.
> 
> And, all this said, the general assumption implied in this PR which linked lists are just to be avoided doesn't match my experience. If you want a "pay only as much memory as you use" data structure, you don't care about random access (e.g. all accesses are linear walks), a linked list is a perfectly fine choice. If there are use cases in the JDK where a LinkedList is used in places where it shouldn't be, then obviously _those cases_ should be replaced.

Hi @mcimadamore, @dfuch after your review comments I've decided to do a deeper investigation for this. First, I've decided to check whether empty `LinkedList` is going to have smaller footprint (this could be fruitful for cases when the list is likely to remain empty in vast majority of cases, see e.g. `URLClassPath.closeLoaders()`), and apparently it isn't:

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class EmptyListBenchmark {
    @Benchmark
    public Object emptyArrayList() { return new ArrayList<>(); }

    @Benchmark
    public Object emptyLinkedList() { return new LinkedList<>(); }
}

This benchmark with my ad-hoc JDK build yields the following results:

Benchmark                                                            Mode  Cnt     Score     Error   Units
EmptyListBenchmark.emptyArrayList                                    avgt   20     4.605 ?   0.463   ns/op
EmptyListBenchmark.emptyArrayList:?gc.alloc.rate.norm                avgt   20    24.002 ?   0.001    B/op
EmptyListBenchmark.emptyLinkedList                                   avgt   20     4.324 ?   0.081   ns/op
EmptyListBenchmark.emptyLinkedList:?gc.alloc.rate.norm               avgt   20    32.002 ?   0.001    B/op

After JDK-8011200 `ArrayList` instantiated with default constructor doesn't allocate underlying array any more.

However the things get more complicated when the list gets populated:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class NonEmptyListBenchmark {
    @Param({"1", "2", "3", "4", "5"})
    private int size;

    @Benchmark
    public Object arrayList() {
        var list = new ArrayList<>();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }

    @Benchmark
    public Object linkedList() {
        var list = new LinkedList<Object>();
        for (int i = 0; i < size; i++) {
            list.add(i);
        }
        return list;
    }
}

Here indeed `ArrayList` looses in memory comapring to `LinkedList` in single-item case:

arrayList:?gc.alloc.rate.norm                       1  avgt   40    80.005 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       2  avgt   40    80.006 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       3  avgt   40    80.007 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       4  avgt   40    80.008 ?   0.001    B/op
arrayList:?gc.alloc.rate.norm                       5  avgt   40    80.008 ?   0.001    B/op

linkedList:?gc.alloc.rate.norm                      1  avgt   40    56.004 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      2  avgt   40    80.005 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      3  avgt   40   104.007 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      4  avgt   40   128.009 ?   0.001    B/op
linkedList:?gc.alloc.rate.norm                      5  avgt   40   152.010 ?   0.001    B/op

And indeed there's at least one usecase in affected files where this is real-life scenario - `JarIndex`. Below on screenshot I run Spring Boot tests with Gradle:

![image](https://d.radikal.ru/d26/2105/d0/a5d588f282e6.png)

However, for the same scenario one node represented with `LinkedList` can hold dozens of items:

![image](https://c.radikal.ru/c38/2105/da/80e6a78cec08.png)

To fix this I propose to instantiate `ArrayList` with initial size = 1:

@Benchmark
public Object arrayList_sized() {
  var list = new ArrayList<>(1);
  list.add(new Object());
  return list;
}

This reduces the footprint of a list with 1 element down to 48 bytes:

arrayList_sized:?gc.alloc.rate.norm                      1  avgt   40    48.004 ?   0.001    B/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 12:03:29 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 12:03:29 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v3]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <vpf2VK08qtqfPTsmiJsA-VjgOQysMmJ19_EanigGiJM=.469a1e68-cbdf-4d05-aede-f1817e225169@github.com>

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8263561: Use sized constructor where reasonable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/158006c6..40910fae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Tue May 25 13:44:14 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 25 May 2021 13:44:14 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList [v4]
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <8QDoLOsBNG7VYDd7ryDVkNTHt9Z-T9QeZ2ll0bWGonQ=.0335a58a-744f-4acc-a226-6c3abbc14914@github.com>

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

?????? ??????? 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 five additional commits since the last revision:

 - Merge branch 'master' into purge-linked-list
 - 8263561: Use sized constructor where reasonable
 - 8263561: Use interface List instead of particular type where possible
 - 8263561: Rename requestList -> requests
 - 8263561: Re-examine uses of LinkedList

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2744/files
  - new: https://git.openjdk.java.net/jdk/pull/2744/files/40910fae..89160b3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=02-03

  Stats: 763526 lines in 11131 files changed: 166175 ins; 560683 del; 36668 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

PR: https://git.openjdk.java.net/jdk/pull/2744

From wetmore at openjdk.java.net  Tue May 25 19:41:37 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 25 May 2021 19:41:37 GMT
Subject: Integrated: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
In-Reply-To: <MLuZ7O6Lhp3hKoB-oRwHRsz6Ki7RAU2Uv0nZmOb7H8E=.550d8995-bdac-4fe2-aa1d-29003a94ee16@github.com>
References: <MLuZ7O6Lhp3hKoB-oRwHRsz6Ki7RAU2Uv0nZmOb7H8E=.550d8995-bdac-4fe2-aa1d-29003a94ee16@github.com>
Message-ID: <PSA26J1H9H27clXVxBWkK8nR9on4k8Cy63UO5v-6ouM=.4453a13b-453b-4b7d-8cb3-09350f14209e@github.com>

On Tue, 25 May 2021 18:03:51 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.
> 
> Resulting javadoc output now compiles.

This pull request has now been integrated.

Changeset: e751b7b1
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e751b7b1b6f7269a1fe20c07748c726536388f6d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc

Reviewed-by: coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/4193

From wetmore at openjdk.java.net  Tue May 25 21:53:39 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 25 May 2021 21:53:39 GMT
Subject: RFR: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
Message-ID: <MLuZ7O6Lhp3hKoB-oRwHRsz6Ki7RAU2Uv0nZmOb7H8E=.3b64ad97-8130-4a9a-ba0d-9dcae4f6ab68@github.com>

Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.

Resulting javadoc output now compiles.

-------------

Commit messages:
 - Codereview Comments.
 - 8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc

Changes: https://git.openjdk.java.net/jdk/pull/4193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4193&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267683
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4193/head:pull/4193

PR: https://git.openjdk.java.net/jdk/pull/4193

From coffeys at openjdk.java.net  Tue May 25 21:53:42 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 25 May 2021 21:53:42 GMT
Subject: RFR: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
In-Reply-To: <MLuZ7O6Lhp3hKoB-oRwHRsz6Ki7RAU2Uv0nZmOb7H8E=.3b64ad97-8130-4a9a-ba0d-9dcae4f6ab68@github.com>
References: <MLuZ7O6Lhp3hKoB-oRwHRsz6Ki7RAU2Uv0nZmOb7H8E=.3b64ad97-8130-4a9a-ba0d-9dcae4f6ab68@github.com>
Message-ID: <A9XD4ykF4BLs6WCXc_0qaKUaPfWli9EhxkYVM6icnJI=.4a1a3149-7a1f-4958-aeac-ab998e756f35@github.com>

On Tue, 25 May 2021 18:03:51 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.
> 
> Resulting javadoc output now compiles.

Looks good!

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4193

From wetmore at openjdk.java.net  Wed May 26 01:19:23 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 26 May 2021 01:19:23 GMT
Subject: RFR: 8267750: Incomplete fix for JDK-8267683
Message-ID: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>

Missed updating today's changeset with the new variable name.

It's a "one character fix."

-------------

Commit messages:
 - 8267750: Incomplete fix for JDK-8267683

Changes: https://git.openjdk.java.net/jdk/pull/4196/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4196&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267750
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4196.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4196/head:pull/4196

PR: https://git.openjdk.java.net/jdk/pull/4196

From jnimeh at openjdk.java.net  Wed May 26 03:02:14 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 26 May 2021 03:02:14 GMT
Subject: RFR: 8267750: Incomplete fix for JDK-8267683
In-Reply-To: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
References: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
Message-ID: <SZscTQlKq8p2R9H3a8V8RQfeowT9vfIGu4oQpCWWGMA=.dee4a3d2-163f-4635-a9ac-1357208c8ede@github.com>

On Wed, 26 May 2021 01:12:14 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Missed updating today's changeset with the new variable name.
> 
> It's a "one character fix."

Looks good.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4196

From wetmore at openjdk.java.net  Wed May 26 03:21:17 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 26 May 2021 03:21:17 GMT
Subject: Integrated: 8267750: Incomplete fix for JDK-8267683
In-Reply-To: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
References: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
Message-ID: <tkmUbz1WHvRgtxxiSRo5jnoAYp1TdQQdwD3sGc9F4nY=.94e2a57a-0cdd-484b-91d1-282b47a99e86@github.com>

On Wed, 26 May 2021 01:12:14 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Missed updating today's changeset with the new variable name.
> 
> It's a "one character fix."

This pull request has now been integrated.

Changeset: b33b8bc8
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b33b8bc88da3afe4f9f6321673df061ea4196962
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267750: Incomplete fix for JDK-8267683

Reviewed-by: jnimeh

-------------

PR: https://git.openjdk.java.net/jdk/pull/4196

From jiefu at openjdk.java.net  Wed May 26 04:04:22 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 04:04:22 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
Message-ID: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>

Hi all,

java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.

The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
[2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
[3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

-------------

Commit messages:
 - 8267353: java/net/SctpSanity.java fails due to Protocol not supported

Changes: https://git.openjdk.java.net/jdk/pull/4199/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4199&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267353
  Stats: 21 lines in 1 file changed: 19 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4199.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4199/head:pull/4199

PR: https://git.openjdk.java.net/jdk/pull/4199

From chris.hegarty at oracle.com  Wed May 26 13:58:02 2021
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 26 May 2021 13:58:02 +0000
Subject: New Networking Group Member: Daniel Fuchs
Message-ID: <1A4685AA-425E-43E6-8753-ACEE571AF12E@oracle.com>

The vote for Daniel Fuchs [1] is now closed.

Yes: 3
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

-Chris.

[1] https://mail.openjdk.java.net/pipermail/net-dev/2021-May/015847.html


From alanb at openjdk.java.net  Wed May 26 14:08:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 May 2021 14:08:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <LsTGOh3OUkeWugrioIVvN7TpAVlN5p_JRHJvxRI7wW8=.1452911e-6343-4716-af03-883e32b8e643@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

I think this looks okay and aligns with Util.isSCTPSupported in test/jdk/com/sun/nio/sctp. One thing that I'm not 100% sure about is why we have a sanity test in test/jdk/java/net, @ChrisHegarty may remember.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From chegar at openjdk.java.net  Wed May 26 14:20:14 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 26 May 2021 14:20:14 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <0uMEuIC2mgkZE3oCgTGrJ8ps4ww5QEBUTKApL1qOYcw=.05aaa439-2385-47f9-b35f-8e31218db2b3@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

This is probably ok, but a little surprising. Can you say a more about the machine setup?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From dfuchs at openjdk.java.net  Wed May 26 14:28:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 26 May 2021 14:28:16 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <pvjp09kM7W0vY0cr7IhK1MH1KoiHaRja4kLbh1b9_To=.46280c41-ec15-466f-a991-a571579970d9@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

I am intrigued - which exception do you get on the machine where SCTP is not supported?
SctpChannel.open() is supposed to throw `UnsupportedOperationException` - If the SCTP protocol is not supported, and the test catches  `UnsupportedOperationException`. 

Note: I don't have objection to the proposed fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 14:35:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 14:35:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <pvjp09kM7W0vY0cr7IhK1MH1KoiHaRja4kLbh1b9_To=.46280c41-ec15-466f-a991-a571579970d9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <pvjp09kM7W0vY0cr7IhK1MH1KoiHaRja4kLbh1b9_To=.46280c41-ec15-466f-a991-a571579970d9@github.com>
Message-ID: <XIgx6ZV0oQelotoX4tsHmi8NMjrCgw3j5Gfpg411Qo4=.afd401c0-f9d7-45d5-a2fc-23539348fce0@github.com>

On Wed, 26 May 2021 14:23:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I am intrigued - which exception do you get on the machine where SCTP is not supported?

Hi @dfuch , we got this exception, which was copied from the JBS.


java.net.SocketException: Protocol not supported
        at jdk.sctp/sun.nio.ch.sctp.SctpNet.socket0(Native Method)
        at jdk.sctp/sun.nio.ch.sctp.SctpNet.socket(SctpNet.java:81)
        at jdk.sctp/sun.nio.ch.sctp.SctpChannelImpl.<init>(SctpChannelImpl.java:138)
        at jdk.sctp/com.sun.nio.sctp.SctpChannel.open(SctpChannel.java:170)
        at SctpSanity.testSctpChannel(SctpSanity.java:58)
        at SctpSanity.main(SctpSanity.java:50)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
        at java.base/java.lang.Thread.run(Thread.java:831)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 14:35:14 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 14:35:14 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <0uMEuIC2mgkZE3oCgTGrJ8ps4ww5QEBUTKApL1qOYcw=.05aaa439-2385-47f9-b35f-8e31218db2b3@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <0uMEuIC2mgkZE3oCgTGrJ8ps4ww5QEBUTKApL1qOYcw=.05aaa439-2385-47f9-b35f-8e31218db2b3@github.com>
Message-ID: <cw8XtWF9-oB_wVNQA24fg5sRyI1qjcMzCxNbLU0BpR4=.452a500b-9115-40a5-b159-85981b194d8a@github.com>

On Wed, 26 May 2021 14:17:18 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> This is probably ok, but a little surprising. Can you say a more about the machine setup?

What do you mean by `setup`?
And how can I get these setups?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From alanb at openjdk.java.net  Wed May 26 14:39:12 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 May 2021 14:39:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <XIgx6ZV0oQelotoX4tsHmi8NMjrCgw3j5Gfpg411Qo4=.afd401c0-f9d7-45d5-a2fc-23539348fce0@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <pvjp09kM7W0vY0cr7IhK1MH1KoiHaRja4kLbh1b9_To=.46280c41-ec15-466f-a991-a571579970d9@github.com>
 <XIgx6ZV0oQelotoX4tsHmi8NMjrCgw3j5Gfpg411Qo4=.afd401c0-f9d7-45d5-a2fc-23539348fce0@github.com>
Message-ID: <e8vR-kMXBOdDF_ly4ivLkaPGPpq4p08ww5V2GDFpfOw=.aecc3a44-2034-4259-8ef7-38b36e90beb8@github.com>

On Wed, 26 May 2021 14:31:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> java.net.SocketException: Protocol not supported
>         at jdk.sctp/sun.nio.ch.sctp.SctpNet.socket0(Native Method)

Do we know if the socket(IPPROTO_SCTP) or setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing? I would have expected the former to check for the not supported case (and the latter to close the fd, but that is a separate issue).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From chegar at openjdk.java.net  Wed May 26 14:44:14 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 26 May 2021 14:44:14 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <cw8XtWF9-oB_wVNQA24fg5sRyI1qjcMzCxNbLU0BpR4=.452a500b-9115-40a5-b159-85981b194d8a@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <0uMEuIC2mgkZE3oCgTGrJ8ps4ww5QEBUTKApL1qOYcw=.05aaa439-2385-47f9-b35f-8e31218db2b3@github.com>
 <cw8XtWF9-oB_wVNQA24fg5sRyI1qjcMzCxNbLU0BpR4=.452a500b-9115-40a5-b159-85981b194d8a@github.com>
Message-ID: <FgvwF_0NoqUEE2xM2MNgs80yESXLsfIQNw8Y0eJqw6Y=.1c6f5613-07dd-4cc9-8aa6-235c0985f83a@github.com>

On Wed, 26 May 2021 14:32:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > This is probably ok, but a little surprising. Can you say a more about the machine setup?
> 
> What do you mean by `setup`?
> And how can I get these setups?
> Thanks.

Let me rephrase.

You said: "The reason is that the test fails to detect all the cases when a machine doesn't support SCTP."

My question is: Please explain the case (or set of cases) where your "machine doesn't support SCTP" ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 14:53:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 14:53:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <YkdsjdzqTg6TNXfPpThFKgclJoUeuzNruLgl1ZMP7WY=.f51fc3b4-590a-40b9-a1ad-743b909dc1fd@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

> Do we know if the socket(IPPROTO_SCTP) or setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing?



> > > This is probably ok, but a little surprising. Can you say a more about the machine setup?
> > 
> > 
> > What do you mean by `setup`?
> > And how can I get these setups?
> > Thanks.
> 
> Let me rephrase.
> 
> You said: "The reason is that the test fails to detect all the cases when a machine doesn't support SCTP."
> 
> My question is: Please explain the case (or set of cases) where your "machine doesn't support SCTP" ?

I'm not an expert in this area.
I don't know how to figure out why my machine don't support SCTP.
Any suggestions?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 14:53:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 14:53:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <YkdsjdzqTg6TNXfPpThFKgclJoUeuzNruLgl1ZMP7WY=.f51fc3b4-590a-40b9-a1ad-743b909dc1fd@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <YkdsjdzqTg6TNXfPpThFKgclJoUeuzNruLgl1ZMP7WY=.f51fc3b4-590a-40b9-a1ad-743b909dc1fd@github.com>
Message-ID: <PxgQNk-g9vqTyVVRKsom7RG0G7Xb2q7OQoQxtGwM44w=.e4f0e1a6-0b10-4736-b5a4-10204d5f6c7b@github.com>

On Wed, 26 May 2021 14:50:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Do we know if the socket(IPPROTO_SCTP) or setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing?

How can I get to know if the socket(IPPROTO_SCTP) or setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing?
Any suggestions?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 14:58:17 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 14:58:17 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <DUiwe6uwoAXcoRBKzXNX1fE6yM3aWKVQnFSpAQo4LQw=.d6620e72-957a-4496-8a74-f2a5728eeb20@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

java/net/SctpSanity.java is the only one, which failed on the machine.
Other sctp related tests like jdk/com/sun/nio/sctp/SctpChannel/Connect.java are all fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From alanb at openjdk.java.net  Wed May 26 15:01:18 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 May 2021 15:01:18 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <PxgQNk-g9vqTyVVRKsom7RG0G7Xb2q7OQoQxtGwM44w=.e4f0e1a6-0b10-4736-b5a4-10204d5f6c7b@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <YkdsjdzqTg6TNXfPpThFKgclJoUeuzNruLgl1ZMP7WY=.f51fc3b4-590a-40b9-a1ad-743b909dc1fd@github.com>
 <PxgQNk-g9vqTyVVRKsom7RG0G7Xb2q7OQoQxtGwM44w=.e4f0e1a6-0b10-4736-b5a4-10204d5f6c7b@github.com>
Message-ID: <jdoQT0QsYKJXZDouampjqleeCDYt-6gZ58463fND3nM=.3f480fe2-b86c-4d57-9c23-5b41f873058d@github.com>

On Wed, 26 May 2021 14:51:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> How can I get to know if the socket(IPPROTO_SCTP) or setsockopt(IPPROTO_SCTP/SCTP_EVENTS) is failing?

`strace -f` should help, or just add trace message. If socket(IPPROTO_SCTP) is failing then it suggests to me that we are missing the check for ENOPROTO.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Wed May 26 15:18:12 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 26 May 2021 15:18:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <jdoQT0QsYKJXZDouampjqleeCDYt-6gZ58463fND3nM=.3f480fe2-b86c-4d57-9c23-5b41f873058d@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <YkdsjdzqTg6TNXfPpThFKgclJoUeuzNruLgl1ZMP7WY=.f51fc3b4-590a-40b9-a1ad-743b909dc1fd@github.com>
 <PxgQNk-g9vqTyVVRKsom7RG0G7Xb2q7OQoQxtGwM44w=.e4f0e1a6-0b10-4736-b5a4-10204d5f6c7b@github.com>
 <jdoQT0QsYKJXZDouampjqleeCDYt-6gZ58463fND3nM=.3f480fe2-b86c-4d57-9c23-5b41f873058d@github.com>
Message-ID: <-OMn_ICBlUeNbLTxzw3AL6djbv0mZ3vZ-OWuOH6QHtc=.7264181f-f092-4891-bc0d-d507ac351f1a@github.com>

On Wed, 26 May 2021 14:58:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> `strace -f` should help, or just add trace message.

Thanks for your help @AlanBateman .
I got the following msg (Connection timed out).

[pid 93582] socket(PF_INET, SOCK_STREAM, IPPROTO_SCTP <unfinished ...>
[pid 93557] <... futex resumed> )       = -1 ETIMEDOUT (Connection timed out)
[pid 93557] futex(0x2b05c03cff78, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 93557] getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0
[pid 93557] getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0
[pid 93557] getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0
[pid 93557] getrusage(0x1 /* RUSAGE_??? */, {ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 0
[pid 93557] futex(0x2b05c03cffa4, FUTEX_WAIT_BITSET_PRIVATE, 5, {10828639, 700862386}, ffffffff <unfinished ...>
[pid 93582] <... socket resumed> )      = -1 EPROTONOSUPPORT (Protocol not supported)

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From alanb at openjdk.java.net  Wed May 26 15:41:22 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 May 2021 15:41:22 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <Gt_D0jb95OShmp65pGnymvqK6WKGfFOHNgVwZm9jZUw=.22c8dfda-bb4e-485a-b228-c5e06122d18b@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

Okay, so I think the issue is that EPROTONOSUPPORT is not handled as I would have expected that to cause UOE to be thrown. I suspect the isSCTPSupported check in Util.java (used by the tests in jdk/test/com/sun/nio/sctp) are masking this. My memory is that there were several relilability issues with SCTP in the early days and it might be that this is why they skip when any error is returned creating the SCTP socket.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From chegar at openjdk.java.net  Wed May 26 15:44:12 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 26 May 2021 15:44:12 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <twINKKGD2pXXoayP0r7RpBE85g8P8UGb1zquVVS9Fyo=.b76d3881-c3c2-4744-8f6a-895b0151fc57@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

There is no check for ENOPROTO in the JDK SCTP code. There is an implicit assumption that SCTP is "supported" when the native libsctp.so.1 library successfully loads and can be introspected. Maybe there should be an explicit ENOPROTO in Java_sun_nio_ch_sctp_SctpNet_socket0.

Maybe the machine in question has the libsctp.so.1 library, but the kernel module is not loaded or something?


$ which checksctp

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From msheppar at openjdk.java.net  Wed May 26 16:13:20 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Wed, 26 May 2021 16:13:20 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

if sctp is configured on a linux system would there exist a  /proc/net/sctp  and have an entry in /proc/net/protocols ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Thu May 27 00:27:06 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 May 2021 00:27:06 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>
Message-ID: <TKsWBvgaa8tzlR4W1oZMyNy28K5HrnX_j6YjeW-0WiE=.92492ae9-085d-40fd-845e-b8a414b312da@github.com>

On Wed, 26 May 2021 16:10:17 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?

No /proc/net/sctp and no entry in /proc/net/protocols.
But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Thu May 27 00:41:04 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 May 2021 00:41:04 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <twINKKGD2pXXoayP0r7RpBE85g8P8UGb1zquVVS9Fyo=.b76d3881-c3c2-4744-8f6a-895b0151fc57@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <twINKKGD2pXXoayP0r7RpBE85g8P8UGb1zquVVS9Fyo=.b76d3881-c3c2-4744-8f6a-895b0151fc57@github.com>
Message-ID: <t9z--5AyfVDKLyAcBXiKBMqPLsO9M0c7-HDTHvkJGS8=.6ee4e3be-ef30-4f2b-a402-df279fe9b0ce@github.com>

On Wed, 26 May 2021 15:41:26 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Maybe the machine in question has the libsctp.so.1 library, but the kernel module is not loaded or something?

Yes, you are right.
We do have libsctp.so.1 and no kernel module.

So what's your suggestion next?
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Thu May 27 00:44:05 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 May 2021 00:44:05 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <TKsWBvgaa8tzlR4W1oZMyNy28K5HrnX_j6YjeW-0WiE=.92492ae9-085d-40fd-845e-b8a414b312da@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>
 <TKsWBvgaa8tzlR4W1oZMyNy28K5HrnX_j6YjeW-0WiE=.92492ae9-085d-40fd-845e-b8a414b312da@github.com>
Message-ID: <kdfjfBkXpnMOxap4Dq3LeuwaIn1hZoMErUlkHqG1A8o=.7363cc95-24ce-459f-85b4-50d375608bc5@github.com>

On Thu, 27 May 2021 00:24:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?
> 
> No /proc/net/sctp and no entry in /proc/net/protocols.
> But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
> Thanks.

After `sudo yum install lksctp-tools`, which would install libsctp.so.1, both the machines fail now.
So @ChrisHegarty is right: the machine in question has the libsctp.so.1 library, but the kernel module is not loaded.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From chegar at openjdk.java.net  Thu May 27 08:31:10 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 27 May 2021 08:31:10 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <kdfjfBkXpnMOxap4Dq3LeuwaIn1hZoMErUlkHqG1A8o=.7363cc95-24ce-459f-85b4-50d375608bc5@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>
 <TKsWBvgaa8tzlR4W1oZMyNy28K5HrnX_j6YjeW-0WiE=.92492ae9-085d-40fd-845e-b8a414b312da@github.com>
 <kdfjfBkXpnMOxap4Dq3LeuwaIn1hZoMErUlkHqG1A8o=.7363cc95-24ce-459f-85b4-50d375608bc5@github.com>
Message-ID: <XHNXmBIaWN9xlGwb2GCcGCV4tlKtkDghjSajgFe8zyU=.055bba39-8844-4cda-8779-111def6da67c@github.com>

On Thu, 27 May 2021 00:41:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?
>> 
>> No /proc/net/sctp and no entry in /proc/net/protocols.
>> But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
>> Thanks.
>
>> > if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?
>> 
>> No /proc/net/sctp and no entry in /proc/net/protocols.
>> But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
>> Thanks.
> 
> After `sudo yum install lksctp-tools`, which would install libsctp.so.1, both the machines fail now.
> So @ChrisHegarty is right: the machine in question has the libsctp.so.1 library, but the kernel module is not loaded.
> Thanks.

@DamonFool Thanks for checking this, and helping track down the root cause of the issue.

The machine configuration is a little unusual (since it has the user-level libraries installed, while the kernel module is not loaded). Clearly, to workaround the issue, the "sctp" kernel module could be loaded, but that will just serve to mask/hide the underlying problem.

The bug is really in the Java_sun_nio_ch_sctp_SctpNet_socket0 native method ( SctpNet.c ) - there should be an explicit check for ENOPROTO after calling socket(2), throwing UnsupportedOperationException if that is the case.

@DamonFool  I would much prefer to keep the test as it is and fix the underlying bug, but this may be more than you want to do? If so, I'll get this done myself.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Thu May 27 08:31:10 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 May 2021 08:31:10 GMT
Subject: RFR: 8267353: java/net/SctpSanity.java fails due to Protocol not
 supported
In-Reply-To: <kdfjfBkXpnMOxap4Dq3LeuwaIn1hZoMErUlkHqG1A8o=.7363cc95-24ce-459f-85b4-50d375608bc5@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
 <b8AtgYZhCVZedWOabPu7S5PsnC5DVgqcgC-FXRpK7hQ=.b64be0bb-c4b1-4346-9dc8-4e95c0b7d09f@github.com>
 <TKsWBvgaa8tzlR4W1oZMyNy28K5HrnX_j6YjeW-0WiE=.92492ae9-085d-40fd-845e-b8a414b312da@github.com>
 <kdfjfBkXpnMOxap4Dq3LeuwaIn1hZoMErUlkHqG1A8o=.7363cc95-24ce-459f-85b4-50d375608bc5@github.com>
Message-ID: <wkaUFuzD-_s9F-bZQXsaYhrGs5lTsYVzBALdMqGRSIE=.c6ae7039-4b18-4112-9674-f1138ad30a63@github.com>

On Thu, 27 May 2021 00:41:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?
>> 
>> No /proc/net/sctp and no entry in /proc/net/protocols.
>> But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
>> Thanks.
>
>> > if sctp is configured on a linux system would there exist a /proc/net/sctp and have an entry in /proc/net/protocols ?
>> 
>> No /proc/net/sctp and no entry in /proc/net/protocols.
>> But I don't think it's the reason since it passed on another machine without /proc/net/sctp and the entry too.
>> Thanks.
> 
> After `sudo yum install lksctp-tools`, which would install libsctp.so.1, both the machines fail now.
> So @ChrisHegarty is right: the machine in question has the libsctp.so.1 library, but the kernel module is not loaded.
> Thanks.

> @DamonFool I would much prefer to keep the test as it is and fix the underlying bug, but this may be more than you want to do? If so, I'll get this done myself.

Please feel free to do so.
I'll close this pr soon.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From jiefu at openjdk.java.net  Thu May 27 08:31:11 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 27 May 2021 08:31:11 GMT
Subject: Withdrawn: 8267353: java/net/SctpSanity.java fails due to Protocol
 not supported
In-Reply-To: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
References: <rIy8uAX1MKEh7warvZWF_Y100ct8_YjoLkaM7sQwIo0=.b28a20d2-15d2-4045-b422-baa349d9dff9@github.com>
Message-ID: <9B-6eVrGyBNU-XlImLPIKFLaICq8fqf4HaRdi3H7FDg=.ff0ac5ad-504c-45f0-8338-31b3959673d3@github.com>

On Wed, 26 May 2021 03:54:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/net/SctpSanity.java fails on some of our test machines due to Protocol not supported.
> The reason is that the test fails to detect all the cases when a machine doesn't support SCTP.
> 
> The fix just follows what are done in [1][2][3] to detect unsupported paltforms at the beginning.
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpMultiChannel/Util.java#L59
> [2] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpServerChannel/Util.java#L59
> [3] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/nio/sctp/SctpChannel/Util.java#L59

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4199

From dfuchs at openjdk.java.net  Thu May 27 09:40:16 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 27 May 2021 09:40:16 GMT
Subject: RFR: 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests
 fail with "IOException: No buffer space available"
Message-ID: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>

Hi,

Please find below a fix for:
8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"

The Pending* websocket tests create a server that accepts sockets to create a websocket, but never read data from the websocket in order to get the client side to block once the buffers are full.
Unfortunately, the PendingOperations:cleanup methods was not called after each test methods invocations, causing sockets to leak and relying on the gc to cleanup.

This caused an "IOException: No buffer space available" to be raised intermittently but reliably (1 run out of 50 in PendingTextPingClose).

The fix makes sure that cleanup() is called appropriately after each test method invocation.
It also tweaks PendingTextPingClose - which seemed to be failing more frequently - to use smaller send and receive buffers in order to reach the point at which the client bocks more quickly and avoid wasting system resources.

-------------

Commit messages:
 - 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"

Changes: https://git.openjdk.java.net/jdk/pull/4222/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4222&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265367
  Stats: 135 lines in 14 files changed: 83 ins; 24 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4222.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4222/head:pull/4222

PR: https://git.openjdk.java.net/jdk/pull/4222

From dfuchs at openjdk.java.net  Thu May 27 13:20:26 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 27 May 2021 13:20:26 GMT
Subject: RFR: 8265367: [macos-aarch64] 3 java/net/httpclient/websocket
 tests fail with "IOException: No buffer space available" [v2]
In-Reply-To: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>
References: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>
Message-ID: <7aNHQnAkDybo1nrsPRVtJYqo7nEajx9hyHuVYOAp7hQ=.40a4ae90-96d0-403e-aefc-fd41976e2348@github.com>

> Hi,
> 
> Please find below a fix for:
> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"
> 
> The Pending* websocket tests create a server that accepts sockets to create a websocket, but never read data from the websocket in order to get the client side to block once the buffers are full.
> Unfortunately, the PendingOperations:cleanup methods was not called after each test methods invocations, causing sockets to leak and relying on the gc to cleanup.
> 
> This caused an "IOException: No buffer space available" to be raised intermittently but reliably (1 run out of 50 in PendingTextPingClose).
> 
> The fix makes sure that cleanup() is called appropriately after each test method invocation.
> It also tweaks PendingTextPingClose - which seemed to be failing more frequently - to use smaller send and receive buffers in order to reach the point at which the client bocks more quickly and avoid wasting system resources.

Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:

 - Added missing spaces after catch
 - Added missing brace in comment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4222/files
  - new: https://git.openjdk.java.net/jdk/pull/4222/files/268e54e6..94c44add

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4222&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4222&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4222.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4222/head:pull/4222

PR: https://git.openjdk.java.net/jdk/pull/4222

From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <H7MsI2j2yC_J1L8fMRTnkpux-4PgkOQxeyDz0ELoIeI=.20958a80-c57b-487b-bac7-644a02bbde72@github.com>
Message-ID: <PVcp8pf1_KCxa_lAv-EYuhfoJ2XJ98AJmKrXQ6a_KEw=.4ce5565b-665e-4b2a-a240-3cfc6ef9e28d@github.com>

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From prr at openjdk.java.net  Thu May 27 17:46:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:46:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

src/java.desktop/share/classes/java/awt/Component.java line 630:

> 628:         }
> 629: 
> 630:         @SuppressWarnings("removal")

I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
that was needed because of the usage in this static block and you could not apply the annotation here.
Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
Can you explain ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <GX7hZeV1Xvkw-CJE9lrU9koQFUCPQDSjpRjG4PeyDHI=.caaead87-2120-4454-bcfd-e80580d7d93a@github.com>
Message-ID: <hhtFKkkecHjmFc0a4jIaZsr7J9jfbBBCIl2z45lU8Rk=.f90b843b-b655-4106-83ee-dcfd9edfdee2@github.com>

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Fri May 28 02:54:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:54:05 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
Message-ID: <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>

On Thu, 27 May 2021 17:42:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update FtpClient.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 630:
> 
>> 628:         }
>> 629: 
>> 630:         @SuppressWarnings("removal")
> 
> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
> that was needed because of the usage in this static block and you could not apply the annotation here.
> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
> Can you explain ?

There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From prr at openjdk.java.net  Fri May 28 03:15:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 May 2021 03:15:12 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
 <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
Message-ID: <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>

On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>> 
>>> 628:         }
>>> 629: 
>>> 630:         @SuppressWarnings("removal")
>> 
>> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
>> that was needed because of the usage in this static block and you could not apply the annotation here.
>> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
>> Can you explain ?
>
> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

Ok. But I will quote you
"This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"

So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.

Why has the explanation changed ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From weijun at openjdk.java.net  Fri May 28 03:22:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 03:22:03 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
 <VHXPRMEIZVe_UgnmbjO2S9neB2ZjBWNCtEoB6VQmEoQ=.28f343f9-888e-4819-b27a-f08b02b978e8@github.com>
 <U7wtFZQMD3K1ydYS7ve7Rgn3f0AQtDQBpta3S1pvpnI=.c48de5eb-d250-4a92-92e9-a3158ce7837c@github.com>
 <whPYE3meJmN84VsHs987fWBJTACWuKncgI5AzVawutA=.7a91414e-1c0e-4895-8ce5-1be384b4b63b@github.com>
Message-ID: <XI0Tn6rP6qjb2gCc3xbHipS_PHau77tF18Ii6wzplLk=.ed4e454b-541d-4545-ae5b-602713b2a6b5@github.com>

On Fri, 28 May 2021 03:12:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.
>
> Ok. But I will quote you
> "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"
> 
> So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.
> 
> Why has the explanation changed ?

I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From chegar at openjdk.java.net  Fri May 28 13:18:19 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 28 May 2021 13:18:19 GMT
Subject: RFR: 8267938: SCTP channel factory methods should check platform
 support
Message-ID: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>

The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.

It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.

The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

-------------

Commit messages:
 - Initial changes

Changes: https://git.openjdk.java.net/jdk/pull/4246/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4246&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267938
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4246.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4246/head:pull/4246

PR: https://git.openjdk.java.net/jdk/pull/4246

From dfuchs at openjdk.java.net  Fri May 28 13:49:06 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 28 May 2021 13:49:06 GMT
Subject: RFR: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
Message-ID: <MNH4D2Kb4MzePaMswTfNjiGub4PAzlUhO5pFztN7e-M=.c2693de3-b811-49d1-9c58-00a30f52745c@github.com>

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.
> 
> It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.
> 
> The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4246

From jiefu at openjdk.java.net  Fri May 28 14:07:07 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 28 May 2021 14:07:07 GMT
Subject: RFR: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
Message-ID: <9czuj40dNIOCv_kcsum26CYxHHwPvXYYMIYygFTmeHs=.b8f0eec7-7c40-43ee-ab5e-5c6c5efcd0bd@github.com>

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.
> 
> It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.
> 
> The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

java/net/SctpSanity.java passed on our machine with this patch.
Thanks for fixing it.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4246

From chegar at openjdk.java.net  Fri May 28 14:09:05 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 28 May 2021 14:09:05 GMT
Subject: RFR: 8265367: [macos-aarch64] 3 java/net/httpclient/websocket
 tests fail with "IOException: No buffer space available" [v2]
In-Reply-To: <7aNHQnAkDybo1nrsPRVtJYqo7nEajx9hyHuVYOAp7hQ=.40a4ae90-96d0-403e-aefc-fd41976e2348@github.com>
References: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>
 <7aNHQnAkDybo1nrsPRVtJYqo7nEajx9hyHuVYOAp7hQ=.40a4ae90-96d0-403e-aefc-fd41976e2348@github.com>
Message-ID: <zVsT7UhZSHDDKhMzY05SiJni4erTJ99I6e-bLKIgUgc=.5803169d-cbd9-4a26-8409-2a035c775b9c@github.com>

On Thu, 27 May 2021 13:20:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hi,
>> 
>> Please find below a fix for:
>> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"
>> 
>> The Pending* websocket tests create a server that accepts sockets to create a websocket, but never read data from the websocket in order to get the client side to block once the buffers are full.
>> Unfortunately, the PendingOperations:cleanup methods was not called after each test methods invocations, causing sockets to leak and relying on the gc to cleanup.
>> 
>> This caused an "IOException: No buffer space available" to be raised intermittently but reliably (1 run out of 50 in PendingTextPingClose).
>> 
>> The fix makes sure that cleanup() is called appropriately after each test method invocation.
>> It also tweaks PendingTextPingClose - which seemed to be failing more frequently - to use smaller send and receive buffers in order to reach the point at which the client bocks more quickly and avoid wasting system resources.
>
> Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Added missing spaces after catch
>  - Added missing brace in comment

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4222

From dfuchs at openjdk.java.net  Fri May 28 14:24:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 28 May 2021 14:24:08 GMT
Subject: Integrated: 8265367: [macos-aarch64] 3 java/net/httpclient/websocket
 tests fail with "IOException: No buffer space available"
In-Reply-To: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>
References: <5wAHHcgbkVD2cd381EkGt8bmEaanpcwAXI5KJThVQD0=.488a07a4-ef52-46d7-9730-f49cd68cbe70@github.com>
Message-ID: <jL-FOD4cfcNn9S2beVBhF6j5Pz3eVQLrrbFGzFZGxUg=.34ade32d-7676-4fb7-8c1d-0bb41ea38eb4@github.com>

On Thu, 27 May 2021 09:32:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find below a fix for:
> 8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"
> 
> The Pending* websocket tests create a server that accepts sockets to create a websocket, but never read data from the websocket in order to get the client side to block once the buffers are full.
> Unfortunately, the PendingOperations:cleanup methods was not called after each test methods invocations, causing sockets to leak and relying on the gc to cleanup.
> 
> This caused an "IOException: No buffer space available" to be raised intermittently but reliably (1 run out of 50 in PendingTextPingClose).
> 
> The fix makes sure that cleanup() is called appropriately after each test method invocation.
> It also tweaks PendingTextPingClose - which seemed to be failing more frequently - to use smaller send and receive buffers in order to reach the point at which the client bocks more quickly and avoid wasting system resources.

This pull request has now been integrated.

Changeset: 24bf35f8
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/24bf35f862e285eeca662b9829901c0f91d247d5
Stats:     138 lines in 14 files changed: 83 ins; 24 del; 31 mod

8265367: [macos-aarch64] 3 java/net/httpclient/websocket tests fail with "IOException: No buffer space available"

Reviewed-by: chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/4222

From alanb at openjdk.java.net  Fri May 28 14:35:04 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 28 May 2021 14:35:04 GMT
Subject: RFR: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
Message-ID: <GU1-xAcHrDVGcZZPgmIO5kVeNBj9hhPv1-_nRs_JDx8=.f2f405a9-dac9-4d5a-98ad-5a4d44937b0e@github.com>

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.
> 
> It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.
> 
> The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

Marked as reviewed by alanb (Reviewer).

EPROTONOSUPPORT and ESOCKTNOSUPPORT are subtly different and I don't know if ESOCKTNOSUPPORT is possible. Checking both errors is okay/harmless so I think this change is okay.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4246

From chegar at openjdk.java.net  Fri May 28 14:45:05 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 28 May 2021 14:45:05 GMT
Subject: RFR: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <GU1-xAcHrDVGcZZPgmIO5kVeNBj9hhPv1-_nRs_JDx8=.f2f405a9-dac9-4d5a-98ad-5a4d44937b0e@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
 <GU1-xAcHrDVGcZZPgmIO5kVeNBj9hhPv1-_nRs_JDx8=.f2f405a9-dac9-4d5a-98ad-5a4d44937b0e@github.com>
Message-ID: <qZjKOpT88KBN27EZ4NKpndqzeIDvTIzR73AbDmWudck=.79c6975f-6800-4695-b41e-b38aa252cb29@github.com>

On Fri, 28 May 2021 14:31:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> EPROTONOSUPPORT and ESOCKTNOSUPPORT are subtly different and I don't know if ESOCKTNOSUPPORT is possible. Checking both errors is okay/harmless so I think this change is okay.

ESOCKTNOSUPPORT is the reported error for SOCK_SEQPACKET (SctpMultiChannel), when the kernel SCTP module is not present.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4246

From vtewari at openjdk.java.net  Fri May 28 18:16:54 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 28 May 2021 18:16:54 GMT
Subject: RFR: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
Message-ID: <qQjXeq3lNKl9p9mBs4BpBFWsB3KelFS2AS71-AvocR0=.206aa637-e6e8-4342-b7de-9ceb702a9fc2@github.com>

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.
> 
> It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.
> 
> The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

Looks OK to me.

-------------

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/4246

From prr at openjdk.java.net  Sun May 30 17:44:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 30 May 2021 17:44:23 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
References: <BPFgU56TN17Hn0kI34aTNy3plbb0Q-5rWwuPzp_54II=.dec7c0dd-2aa2-4ca0-811c-518a12baa0ac@github.com>
 <i22FLT1A2Kf1Bc37uhIjz3sAm9b3NDjEPGsMUrwWYfs=.25c58668-2f52-4371-b339-0765680d7a3b@github.com>
Message-ID: <nJPC4wkzrEB1S-50zDd6rH7nAYjitSHUl02KPNfVYeU=.cdfeb19c-16a2-47ee-b562-bade124de429@github.com>

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138

From chegar at openjdk.java.net  Mon May 31 09:49:24 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 31 May 2021 09:49:24 GMT
Subject: Integrated: 8267938: (sctp) SCTP channel factory methods should check
 platform support
In-Reply-To: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
References: <h5PWBQcEVKYPdx_D0neSfdctjTKIBMPq4bKtHhYOZnU=.2a32e048-f32b-44fa-9c15-4284d0c418dc@github.com>
Message-ID: <VwZRK-hIhrYQG1y5ItqGg5nJ_96lPefrquRS5-Jl_AU=.41676d22-f4aa-4334-a3e8-90b58df07e18@github.com>

On Fri, 28 May 2021 13:11:43 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.
> 
> It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.
> 
> The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

This pull request has now been integrated.

Changeset: bd31653e
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bd31653e6f99d4337e4af1f7f138d688ec99c19d
Stats:     8 lines in 1 file changed: 6 ins; 0 del; 2 mod

8267938: (sctp) SCTP channel factory methods should check platform support

Reviewed-by: dfuchs, jiefu, alanb, vtewari

-------------

PR: https://git.openjdk.java.net/jdk/pull/4246

From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073

From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <TdTmyQQ8Wnh6Ko6yk3xYGN-eN8CCaUiw_W6bh9WbOTc=.8388e5dc-6cf8-4215-be1e-4b98eadb6d4c@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073

From dfuchs at openjdk.java.net  Mon May 31 16:27:33 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 31 May 2021 16:27:33 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the HttpClient
 API
Message-ID: <h30nCsV3UPz3V7TS3ulOF3_uMYN9QwKh2nxPJWmnOG4=.7051e6ac-b07f-4650-a981-80f9aac3491b@github.com>

The Utils.remaining(List<ByteBuffer> list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 

Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

-------------

Commit messages:
 - 8267990: Revisit some uses of `synchronized` in the HttpClient API

Changes: https://git.openjdk.java.net/jdk/pull/4275/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267990
  Stats: 101 lines in 13 files changed: 59 ins; 6 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4275/head:pull/4275

PR: https://git.openjdk.java.net/jdk/pull/4275

From chegar at openjdk.java.net  Mon May 31 16:34:24 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 31 May 2021 16:34:24 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the
 HttpClient API
In-Reply-To: <h30nCsV3UPz3V7TS3ulOF3_uMYN9QwKh2nxPJWmnOG4=.7051e6ac-b07f-4650-a981-80f9aac3491b@github.com>
References: <h30nCsV3UPz3V7TS3ulOF3_uMYN9QwKh2nxPJWmnOG4=.7051e6ac-b07f-4650-a981-80f9aac3491b@github.com>
Message-ID: <RmzsGhnvwGVxAnUim-7Hq1bFgF5Ty4UWmKZl-f4Dp2o=.80238123-b5a5-417a-964d-adf88597372d@github.com>

On Mon, 31 May 2021 16:21:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The Utils.remaining(List<ByteBuffer> list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 
> 
> Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4275

From dfuchs at openjdk.java.net  Mon May 31 16:40:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 31 May 2021 16:40:44 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the
 HttpClient API [v2]
In-Reply-To: <h30nCsV3UPz3V7TS3ulOF3_uMYN9QwKh2nxPJWmnOG4=.7051e6ac-b07f-4650-a981-80f9aac3491b@github.com>
References: <h30nCsV3UPz3V7TS3ulOF3_uMYN9QwKh2nxPJWmnOG4=.7051e6ac-b07f-4650-a981-80f9aac3491b@github.com>
Message-ID: <ad8lxopM0oLh-wMpvsoGyKjLszUjqKrZbJBQrXyE9dE=.30df8bec-177c-4177-a4c5-a3cfbb77cff3@github.com>

> The Utils.remaining(List<ByteBuffer> list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 
> 
> Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  8267990: Revisit some uses of `synchronized` in the HttpClient API

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4275/files
  - new: https://git.openjdk.java.net/jdk/pull/4275/files/c2f49a5f..7d92e7bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4275/head:pull/4275

PR: https://git.openjdk.java.net/jdk/pull/4275