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
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
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
(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
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
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
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
> 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
> 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
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/
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
> 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
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
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:
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:
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
> 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
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
>>
>>
> 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
> 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
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
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
> 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
> 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
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
> 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
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
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
> 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:
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.
> 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:
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
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/?
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
> 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
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
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:
> 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
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
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
> 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
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
> 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
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
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
45 matches
Mail list logo