Object creation from iterating Map.of()/Set.of()/List.of()

2024-02-02 Thread Ryan Ernst
The newer “of” methods in collections are really nice, they make creating these collections much easier and often result in better performance. However, the empty collection cases with Map.of()/Set.of()/List.of() has one small downside. The implementations within ImmutableCollections use non-sp

Re: List extending Collection/SequencedCollection

2023-07-16 Thread Ryan Ernst
out this have been asked on Stack Overflow, and various answers > there have made up a rationale about the possibly-redundant interfaces being > included explicitly because it expresses intent more clearly, or some such. > My own guess is that nobody has paid much attention to this

Re: List extending Collection/SequencedCollection

2023-07-07 Thread Ryan Ernst
s a semantically > equivalent refactoring, I think it is generally fine.) > > HTH, > > -Joe > >> On 6/29/2023 11:30 AM, Ryan Ernst wrote: >> Thanks for replying, Joe. First, let me reiterate, we fully admit >> there was a bug in painless, we stopped short i

Re: List extending Collection/SequencedCollection

2023-06-29 Thread Ryan Ernst
(for the > javax.lang.model API during annotation processing at compile time), but > it is a bug for third party programs to rely on such details. > > HTH, > > -Joe > > On 6/27/2023 7:37 AM, Ryan Ernst wrote: > > Hi core-libs-dev, > > > > I know various t

List extending Collection/SequencedCollection

2023-06-27 Thread Ryan Ernst
Hi core-libs-dev, I know various threads have existed over the past few months on SequencedCollection and its implications on compatibility. I wanted to raise this semi-related issue we noticed recently after beginning testing against Java 21. Elasticsearch began testing against Java 21, and noti

Integrated: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread

2022-11-26 Thread Ryan Ernst
On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote: > This commit guards thread modifications for the process reaper thread with > doPrivileged. This pull request has now been integrated. Changeset: 50f9043c Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openj

Re: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3]

2022-11-26 Thread Ryan Ernst
On Sat, 26 Nov 2022 17:24:02 GMT, Alan Bateman wrote: > Not important but can eliminate the casts from privilegedThreadSetXXX methods > if you separate the creation of the PrivilegedAction from the doPriv call. I chose to keep it as is since there was already another doPriv in the file that us

Re: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3]

2022-11-26 Thread Ryan Ernst
> This commit guards thread modifications for the process reaper thread with > doPrivileged. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: Revert factory method - Changes: - all: https://git.openjdk.org/jd

Re: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v2]

2022-11-26 Thread Ryan Ernst
> This commit guards thread modifications for the process reaper thread with > doPrivileged. Ryan Ernst has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #1 from ChrisHegarty/reaper_thread_modify Add privileged

RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread

2022-11-22 Thread Ryan Ernst
This commit guards thread modifications for the process reaper thread with doPrivileged. - Commit messages: - 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread Changes: https://git.openjdk.org/jdk/pull/11309/files Webrev: https://webrevs.openjdk.org/

Integrated: 8290504: Close streams returned by ModuleReader::list

2022-07-21 Thread Ryan Ernst
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. This pull request has now been integrated. Changeset: 80bd8c35 Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/com

Re: RFR: 8290504: Close streams returned by ModuleReader::list [v4]

2022-07-21 Thread Ryan Ernst
> This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into try_files/module_reader_uses - fix caller s

Re: RFR: 8290504: Close streams returned by ModuleReader::list [v4]

2022-07-21 Thread Ryan Ernst
On Thu, 21 Jul 2022 06:53:53 GMT, Chris Hegarty wrote: >> Done in >> [4a94c64](https://github.com/openjdk/jdk/pull/9557/commits/4a94c645fe1e37abc694f81fd8e401c5dc367d68) > > @rjernst it seems that the _revert_ part of the above has been done, but not > the "have the callerSensitiveMethods DataP

Integrated: 8290359: Ensure that all directory streams are closed in jdk.link

2022-07-20 Thread Ryan Ernst
On Fri, 15 Jul 2022 16:18:17 GMT, Ryan Ernst wrote: > This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. This pull request has now been integrated. Changeset: 3582fd9e Author: Ryan Ernst Committer: Chris Hegarty URL:

Integrated: 8290316: Ensure that all directory streams are closed in java.base

2022-07-20 Thread Ryan Ernst
On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. This pull request has now been integrated. Changeset: 53fc495e Author: Ryan Ernst Committer: Chris Hegarty URL:

Integrated: 8290353: ModuleReader::list specification should suggest closing the returned stream

2022-07-20 Thread Ryan Ernst
On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. This pull request has

Re: RFR: 8290504: Close streams returned by ModuleReader::list [v3]

2022-07-20 Thread Ryan Ernst
> This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: silly spaces - Changes: - all: https://git.openjdk.org/jdk/pull/9557/files - new: ht

Re: RFR: 8290504: Close streams returned by ModuleReader::list [v2]

2022-07-20 Thread Ryan Ernst
On Wed, 20 Jul 2022 20:17:27 GMT, Mandy Chung wrote: >> test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java line >> 411: >> >>> 409: try (ModuleReader reader = mref.open(); >>> 410: Stream stream = reader.list()) { >>> 411: return stream >> >>

Re: RFR: 8290504: Close streams returned by ModuleReader::list [v2]

2022-07-20 Thread Ryan Ernst
> This commit ensures streams returned by ModuleReader::list are closed. Ryan Ernst 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 three additio

Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v4]

2022-07-20 Thread Ryan Ernst
> This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst has updated the pull request with a new target base due to a merge or

Re: RFR: 8290504: Close streams returned by ModuleReader::list

2022-07-19 Thread Ryan Ernst
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote: > This commit ensures streams returned by ModuleReader::list are closed. Note that ModulePatcher::list delegates to ModuleReader::list, but since the stream it builds closes the underlying stream, the use doesn't need to be closed wi

RFR: 8290504: Close streams returned by ModuleReader::list

2022-07-19 Thread Ryan Ernst
This commit ensures streams returned by ModuleReader::list are closed. - Commit messages: - 8290504: Close streams returned by ModuleReader::list Changes: https://git.openjdk.org/jdk/pull/9557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9557&range=00 Issue: https://bug

Re: RFR: 8290353: ModuleReader::list specification should suggest closing the returned stream [v3]

2022-07-19 Thread Ryan Ernst
> This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst has updated the pull request with a new target base due to a merge or

Re: RFR: 8290353: Clarify the streams returned by ModuleReader::list [v2]

2022-07-18 Thread Ryan Ernst
> This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. Ryan Ernst has updated the pull request incrementally with two additional commits

Re: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2]

2022-07-18 Thread Ryan Ernst
On Mon, 18 Jul 2022 15:35:25 GMT, Chris Hegarty wrote: >> Ryan Ernst 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 contain

Re: RFR: 8290359: Ensure that all directory streams are closed in jdk.link [v2]

2022-07-18 Thread Ryan Ernst
> This commit adds try-with-resources for uses of Stream from Files > methods that walk directories. Ryan Ernst 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 r

Re: RFR: 8290353: Clarify the streams returned by ModuleReader::list

2022-07-18 Thread Ryan Ernst
On Mon, 18 Jul 2022 14:06:00 GMT, Ryan Ernst wrote: > This commit adds additional clarification to the javadocs of > ModuleReader::list about needing to close the stream. The new wording is > similar to that used in Files::find and other similar methods. I relaxed the wording in

RFR: 8290353: Clarify the streams returned by ModuleReader::list

2022-07-18 Thread Ryan Ernst
This commit adds additional clarification to the javadocs of ModuleReader::list about needing to close the stream. The new wording is similar to that used in Files::find and other similar methods. - Commit messages: - 8290353: Clarify the streams returned by ModuleReader::list Chang

Re: RFR: 8290316: Ensure that all directory streams are closed in java.base [v3]

2022-07-18 Thread Ryan Ernst
> This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: fix compile and address more feedback - Changes: - all:

Re: RFR: 8290316: Ensure that all directory streams are closed in java.base

2022-07-15 Thread Ryan Ernst
On Fri, 15 Jul 2022 16:06:21 GMT, Ryan Ernst wrote: > This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Thanks Alan. The 8 space indents were unintentional. I think I've addressed all your comments in [c0a09f9](https://github.

Re: RFR: 8290316: Ensure that all directory streams are closed in java.base [v2]

2022-07-15 Thread Ryan Ernst
> This commit guards uses of Files methods returning path streams in > java.base to use try-with-resources. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: address formatting feedback - Changes: - all:

RFR: 8290359: Ensure that all directory streams are closed in jdk.link

2022-07-15 Thread Ryan Ernst
This commit adds try-with-resources for uses of Stream from Files methods that walk directories. - Commit messages: - 8290359: Ensure that all directory streams are closed in jdk.link Changes: https://git.openjdk.org/jdk/pull/9520/files Webrev: https://webrevs.openjdk.org/?repo=jdk

RFR: 8290316: Ensure that all directory streams are closed in java.base

2022-07-15 Thread Ryan Ernst
This commit guards uses of Files methods returning path streams in java.base to use try-with-resources. - Commit messages: - 8290316: Ensure that all directory streams are closed in java.base Changes: https://git.openjdk.org/jdk/pull/9518/files Webrev: https://webrevs.openjdk.org/?

Re: RFR: 8288984: Simplification in Shutdown.exit [v2]

2022-07-06 Thread Ryan Ernst
On Mon, 4 Jul 2022 16:47:28 GMT, Chris Hegarty wrote: >> I think the wording in the latest commit (9d972b) is problematic. One reason >> is that you've changed it to "will run shutdown hooks" but it doesn't run >> the hooks, it starts them, and so conflicts with the previous paragraph. I >> al

Re: RFR: 8288984: Simplification in java.lang.Runtime::exit [v4]

2022-07-06 Thread Ryan Ernst
> This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the

Re: RFR: 8288984: Simplification in Shutdown.exit [v3]

2022-07-05 Thread Ryan Ernst
On Tue, 5 Jul 2022 04:06:03 GMT, David Holmes wrote: >> Signal handlers for eg SIGTERM invoke Shutdown.shutdown. That method holds >> the same lock as Shutdown.exit and runs shutdown hooks. So if a signal >> handler triggers shutdown, and before the system halts Runtime.exit is >> invoked, the

Re: RFR: 8288984: Simplification in Shutdown.exit [v3]

2022-07-05 Thread Ryan Ernst
On Tue, 5 Jul 2022 00:16:50 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional >> commit since the last revision: >> >> iterate on wording > > src/java.base/share/classes/java/lang/Runtime.java line 88:

Re: RFR: 8288984: Simplification in java.lang.Runtime::exit [v5]

2022-07-05 Thread Ryan Ernst
> This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the

Re: RFR: 8288984: Simplification in java.lang.Runtime::exit [v2]

2022-07-05 Thread Ryan Ernst
On Mon, 4 Jul 2022 12:19:27 GMT, David Holmes wrote: >> Ryan Ernst has updated the pull request incrementally with one additional >> commit since the last revision: >> >> better clarify multiple threads behavior > >> Let's say we've run shutdow

Re: RFR: 8288984: Simplification in Shutdown.exit [v2]

2022-07-04 Thread Ryan Ernst
On Mon, 4 Jul 2022 08:42:02 GMT, Alan Bateman wrote: >> +1 - except for the "deadlock" part (see other comment). I think the old >> paragraph is at least confusing, and perhaps even just wrong. Let's say >> we've run `shutdown` so run all the hooks but not halted. Then someone >> calls `exi

Re: RFR: 8288984: Simplification in Shutdown.exit [v3]

2022-07-04 Thread Ryan Ernst
> This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the

Re: RFR: 8288984: Simplification in Shutdown.exit [v2]

2022-07-02 Thread Ryan Ernst
On Sat, 2 Jul 2022 19:32:04 GMT, Alan Bateman wrote: >> If a shutdown hook is running, then shutdown has started, right? This new >> wording isn’t really a change, it’s the current behavior (the “otherwise” >> portion of the old wording). But the wording is meant to be more accurate >> for the

Re: RFR: 8288984: Simplification in Shutdown.exit [v2]

2022-07-02 Thread Ryan Ernst
> This is a followup to simplify Shutdown.exit after the removal of > finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement > on the approach has been reached in this PR, a CSR will be filed to > propose the spec change to Runtime.exit. Ryan Ernst has updated the

Re: RFR: 8288984: Simplification in Shutdown.exit

2022-07-02 Thread Ryan Ernst
On Sat, 2 Jul 2022 13:21:06 GMT, David Holmes wrote: >> This is a followup to simplify Shutdown.exit after the removal of >> finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement >> on the approach has been reached in this PR, a CSR will be filed to >> propose the spec change t

RFR: 8288984: Simplification in Shutdown.exit

2022-07-01 Thread Ryan Ernst
This is a followup to simplify Shutdown.exit after the removal of finalizers (https://bugs.openjdk.org/browse/JDK-8198250). Once agreement on the approach has been reached in this PR, a CSR will be filed to propose the spec change to Runtime.exit. - Commit messages: - 8288984: Simpli