On Tue, 16 Jan 2024 09:11:01 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the un
On Tue, 16 Jan 2024 12:23:43 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
Hi all,
This pull request contains a backport of commit
[ee4d9aa4](https://github.com/openjdk/jdk/commit/ee4d9aa4c11c47e7cf15f2742919ac20311f9ea7)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Chris Hegarty on 16 Jan 2024
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable offer.
This pull request has now been integrated.
Changeset: ee4d9aa4
Author: Chris Hegarty
URL:
https://git.openjdk.org/jdk/com
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty 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 ei
On Mon, 15 Jan 2024 09:49:53 GMT, Alan Bateman wrote:
>> With my CSR hat on, JDK-8301341 should never have made the changes it did
>> without going through a CSR request. We have been bitten by this kind of
>> problem many times. Unless a public method is specified to utilise another
>>
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty 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 se
On Mon, 15 Jan 2024 12:34:57 GMT, Doug Lea wrote:
> Sorry for needlessly calling overridable versions in these two cases. I
> should have caught that.
No problem, easy to overlook. I assume you are ok with the changes? If so,
could I please ask you to add your review. Otherwise, is there
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty 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 f
On Mon, 15 Jan 2024 09:49:39 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> src
On Mon, 15 Jan 2024 07:31:13 GMT, Andrey Turbanov wrote:
>> Chris Hegarty has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> timed offer
>
> src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
Co-autho
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
timed offer
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17393/files
-
On Fri, 12 Jan 2024 15:02:59 GMT, Chris Hegarty wrote:
>> Update LinkedTransferQueue add and put methods to not call overridable offer.
>
> Chris Hegarty has updated the pull request incrementally with one additional
> commit since the last revision:
>
> timed offer
> Update LinkedTransferQueue add and put methods to not call overridable offer.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
add test
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17393/files
- new: ht
On Fri, 12 Jan 2024 10:38:40 GMT, Chris Hegarty wrote:
> Update LinkedTransferQueue add and put methods to not call overridable.
FTR - I agree that it's kinda annoying to be proposing this change and it is
true that the consuming user code is making an assumption, but the imp
On Fri, 12 Jan 2024 11:22:13 GMT, Chris Hegarty wrote:
>>> A process-related comment: this PR is against mainline, but the issue's Fix
>>> Version/s is 22. This will create a bit of a mess if integrated.
>>
>> Thanks for the reminder Pavel. If accepted, then the
On Fri, 12 Jan 2024 11:11:51 GMT, Chris Hegarty wrote:
> this PR is against mainline, but the issue's Fix Version/s is 22.
I updated the fix version in JIRA, and followed the process as outlined in
https://mail.openjdk.org/pipermail/jdk-dev/2023-December/008560.html
-
PR Comm
On Fri, 12 Jan 2024 11:07:17 GMT, Pavel Rappo wrote:
> A process-related comment: this PR is against mainline, but the issue's Fix
> Version/s is 22. This will create a bit of a mess if integrated.
Thanks for the reminder Pavel. If accepted, then the change will be applicable
to 23, 22, and
On Fri, 12 Jan 2024 11:03:02 GMT, Alan Bateman wrote:
> This feels more like a hazard when extending to override behavior.
Yeah, this is certainly a potential issue with any subclass-able class. I
remember seeing similar before in other areas too.
> I think it would be useful to provide a
Update LinkedTransferQueue add and put methods to not call overridable.
-
Commit messages:
- Update LinkedTransferQueue add and put methods to not call overridable offer
Changes: https://git.openjdk.org/jdk/pull/17393/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=17393=00
On Thu, 26 Oct 2023 09:17:25 GMT, Per Minborg wrote:
>> This PR proposes removing the restriction that only heap `MemorySegment`
>> wrapping a `byte` array can be accessed by Vectors. Now any array type can
>> be used provided the element alignment constraints are respected.
>
> Per Minborg
On Wed, 25 Oct 2023 14:01:09 GMT, Maurizio Cimadamore
wrote:
>> This PR proposes removing the restriction that only heap `MemorySegment`
>> wrapping a `byte` array can be accessed by Vectors. Now any array type can
>> be used provided the element alignment constraints are respected.
>
>
Vote: yes
-Chris
> On 25 Aug 2023, at 16:45, Joe Wang wrote:
>
> Vote: yes
>
> -Joe
>
>> On 8/25/23 8:23 AM, Roger Riggs wrote:
>> I hereby nominate Lance Andersen to Membership in the Core Libraries Group
>
Vote: yes
-Chris
> On 26 Aug 2023, at 08:13, Alan Bateman wrote:
>
> Vote: yes
>
Vote: yes
-Chris
> On 26 Aug 2023, at 08:13, Alan Bateman wrote:
>
> Vote: yes
Vote: Yes.
-Chris
On 27/07/2023 19:36, Roger Riggs wrote:
|I hereby nominate Joe Wang||to Membership in the Core Libraries Group Joe has been working in the
core library team since 2012. He has been maintaining and improving
the XML library APIs and implementations including ||DOM, SAX, StAX,
Vote: Yes.
-Chris
On 27/07/2023 19:36, Roger Riggs wrote:
|I hereby nominate |Brent Christian|to Membership in the Core Libraries Group Brent has been working in
the Core Library team at Oracle since 2012. He has made contributions
to many areas of OpenJDK including java.lang strings, class
Vote: Yes.
-Chris
On 27/07/2023 19:35, Roger Riggs wrote:
|I hereby nominate |Brian Burkhalter|to Membership in the Core Libraries Group Brian has been working in
the Core Library team since 2012. Brian's many contributions to the
OpenJDK libraries include java.io subsystems, NIO channels,
On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Fri, 9 Jun 2023 19:44:32 GMT, Chris Hegarty wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
Hi all,
This pull request contains a backport of commit
[cee5724d](https://github.com/openjdk/jdk/commit/cee5724d09b9ef9bd528fb721b756cb052265e3d)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Chris Hegarty on 9 Jun 2023
;
> This is the only such security manager related issue I see in this code, and
> I have looked.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
use loopBound
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14392
On Fri, 9 Jun 2023 18:12:36 GMT, Paul Sandoz wrote:
>> Chris Hegarty has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add at bug and remove newline
>
> test/jdk/jdk/incubator/vector/VectorRuns.java line 74
On Fri, 9 Jun 2023 13:02:18 GMT, Chris Hegarty wrote:
> A trivial use of the Vector API when run with the security manager and a
> domain that does not grant permissions fails with
> java.security.AccessControlException: access denied
> ("java.util.P
;
> This is the only such security manager related issue I see in this code, and
> I have looked.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
add at bug and remove newline
-
Changes:
- all: https://git.openjdk.org
A trivial use of the Vector API when run with the security manager and a domain
that does not grant permissions fails with
java.security.AccessControlException: access denied
("java.util.PropertyPermission" "jdk.incubator.vector.VECTOR_ACCESS_OOB_CHECK"
"read").
The fix it minimal, as
On Fri, 9 Jun 2023 13:02:18 GMT, Chris Hegarty wrote:
> A trivial use of the Vector API when run with the security manager and a
> domain that does not grant permissions fails with
> java.security.AccessControlException: access denied
> ("java.util.P
Hi Stuart,
First, thanks for you detailed reply.
On 25/03/2023 00:16, Stuart Marks wrote:
...
Yes, this has come up before, but it's been mostly theoretical. That is,
people worry about this when they hear of the idea of randomized
iteration order, but I've never heard any followup. This is
I know that this has come up a number of times before, but I cannot seem
to find anything directly relevant to my use-case, or recent.
The iteration order of immutable Sets and Maps (created by the `of`
factories) is clearly unspecified - good. Code should not depend upon
this iteration
Hi,
While definitely not the right list, someone here will surely know ...
Where can I download archive EA builds of JDK 20, so I can perform
bisect experiments to help narrow when something changed between JDK 19
and JDK 20. ( I have some builds, but not that many )
---
Informational: I'm
On Tue, 28 Feb 2023 14:09:50 GMT, Alan Bateman wrote:
>> But does that logging include the thread identity? If multiple threads can
>> race to exit and all log, then the developer/user needs to know which
>> logging came from which thread.
>
>> But does that logging include the thread
On Fri, 17 Feb 2023 17:27:50 GMT, Roger Riggs wrote:
>> It can be difficult to find the cause of calls to
>> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
>> runtime exits.
>> The status value and stack trace are logged using the System Logger named
>>
On Tue, 17 Jan 2023 11:34:52 GMT, Alan Bateman wrote:
> The ModuleReader implementation for exploded modules maps resource names to
> file paths. A small oversight is that it doesn't handle InvalidPathException
> which is thrown when the resource name maps to something that can't be parsed
>
On Mon, 12 Dec 2022 14:26:40 GMT, Per Minborg wrote:
>> This PR proposes making a field in `RandomAccessFile` final. Also, it
>> modernises a switch statement.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Make the field
On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman wrote:
> Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide
> the Class object as the base instead of the base object returned by
> Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM.
LGTM
On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman wrote:
> Another small step in the multi-release/multi-year effort to remove cruft
> from Thread/ThreadGroup.
>
> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and
> the Classic VM. The method controlled whether threads
On Wed, 23 Nov 2022 16:02:37 GMT, Chris Hegarty wrote:
>> I would prefer to to avoid creating new factories when the desired function
>> can be done on the resulting thread.
>> Such as `setDaemon()` and `setName()`, etc.
>> It does avoid the doPriv in this case, but i
On Sat, 26 Nov 2022 15:50:54 GMT, Ryan Ernst wrote:
>> 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
LGTM
On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote:
> This commit guards thread modifications for the process reaper thread with
> doPrivileged.
Changes requested by chegar (Reviewer).
src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 137:
> 135: public static
On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote:
> This commit guards thread modifications for the process reaper thread with
> doPrivileged.
Hi @rjernst Thanks for taking this one on.
I agree with adding the privileged blocks around the calls to Thread::setName,
but the usage raises a
.
Thanks, Roger
On 11/22/22 11:12 AM, Chris Hegarty wrote:
Hi Alan,
On 22/11/2022 16:08, Alan Bateman wrote:
On 22/11/2022 15:21, Chris Hegarty wrote:
..
Just to double check, does the ES security manager override
checkAccess(Thread)?
Yes. :-(
That is usually a no-op but if overridden
Hi Alan,
On 22/11/2022 16:08, Alan Bateman wrote:
On 22/11/2022 15:21, Chris Hegarty wrote:
..
Just to double check, does the ES security manager override
checkAccess(Thread)?
Yes. :-(
That is usually a no-op but if overridden then it
will expose an issue with the thread factory
Hi,
A change in JDK 19, that changed process reaper threads to be
innocuous [1], has had an adverse affect when terminating the
Elasticsearch server [2]. I agree with changing the process reapers to
be innocuous, but just wonder if we're missing a few doPriv blocks.
Additionally, and also in JDK
On Wed, 5 Oct 2022 15:01:15 GMT, Alan Bateman wrote:
> This is a test only change to remove the granting of
> RuntimePermission("stopThread") from the tests. With Thread.stop changed to
> throw UOE it means there is nothing that requires this permission.
LGTM
-
Marked as
On Tue, 9 Aug 2022 09:36:28 GMT, Jaikiran Pai wrote:
> (This is a recreation of a previous pull request which had received some
> reviews https://github.com/openjdk/jdk/pull/9036. I had to delete that
> personal branch and recreate it due to some git issues)
>
> Can I please get a review of
On Thu, 21 Jul 2022 13:23:43 GMT, Ryan Ernst wrote:
>> 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'
On Wed, 20 Jul 2022 20:54:27 GMT, Ryan Ernst wrote:
>> yes, this would solve it.
>
> 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
On Tue, 19 Jul 2022 14:07:17 GMT, Ryan Ernst wrote:
> This commit ensures streams returned by ModuleReader::list are closed.
test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java line 411:
> 409: try (ModuleReader reader = mref.open();
> 410: Stream stream =
On Tue, 19 Jul 2022 14:06:52 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.
>
> Ryan Ernst has updated the pull
On Mon, 18 Jul 2022 18:19:48 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.
>
> Ryan Ernst has updated the pull
On Mon, 18 Jul 2022 19:48:02 GMT, Mark Reinhold wrote:
> It’s odd to mix adding some advice to the Javadoc with adopting that advice
> in the code base. Consider opening a new issue and PR for the actual code
> changes.
[JDK-8290504][1] has been filed to track the implementation changes.
On Mon, 18 Jul 2022 18:22:02 GMT, Ryan Ernst wrote:
>> 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
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.
Changes requested by chegar (Reviewer).
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 834:
> 832:
On Mon, 18 Jul 2022 14:02:47 GMT, Ryan Ernst wrote:
>> 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
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.
Given the recommendation to close
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.
On Sat, 16 Jul 2022 03:35:06 GMT, Bernd wrote:
>> Ryan Ernst has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address formatting feedback
>
> src/java.base/share/classes/java/time/chrono/HijrahChronology.java line 1041:
>
>> 1039:
On Fri, 15 Jul 2022 19:33:56 GMT, Ryan Ernst wrote:
>> 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
On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
On Thu, 7 Jul 2022 06:06:42 GMT, Stuart Marks wrote:
> Minor doc wording changes, to be consistent with HashSet.newHashSet et. al.
LGTM
-
Marked as reviewed by chegar (Reviewer).
PR: https://git.openjdk.org/jdk19/pull/118
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 shutdown so run all the hooks but not halted. Then
>>
On Tue, 5 Jul 2022 18:43:26 GMT, Ryan Ernst 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 to
On Tue, 5 Jul 2022 13:30:40 GMT, Ryan Ernst 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 to
On Tue, 5 Jul 2022 07:23:49 GMT, David Holmes wrote:
>> I like the new suggested wording, but I would slightly tweak it. As Alan
>> mentioned in another comment the first paragraph makes clear the method
>> never returns normally. How does the following sound?
>>
>>> If this method is invoked
On Mon, 4 Jul 2022 16:31:22 GMT, Alan Bateman wrote:
>> I reworded with the suggested text in mind. I also added another sentence
>> referencing native signal handlers, which may also initiate shutdown. I
>> think this clarification is important so that it is clear the status code of
>> all
On Mon, 4 Jul 2022 01:57:11 GMT, Kim Barrett wrote:
> Is "deadlock" accurate?
Yes.
In the context of the specification, "shutdown hook" means _application_
shutdown hook - as far as the specification is concerned, application shutdown
hooks are the only kind of hooks. Right?
For example,
On Sat, 2 Jul 2022 13:23:27 GMT, David Holmes wrote:
> Sorry, I did not think this issue was intended to change the specification in
> any way, but I see now that it actually does - whether that was the intent or
> not.
While, maybe, not strictly envisioned by the JIRA issue, the
On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen wrote:
> Hi,
>
> Please review the following patch which will:
>
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include
> the methods
>
> - public boolean exists(Path path, LinkOption... options)
> - public A
80 matches
Mail list logo
