On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Mon, 7 Jul 2025 03:05:15 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.sinh() using libm. There is a new set of micro-benchmarks are
> included to check the performance of specific input value ranges to help
> prevent regressions in
> The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as
> a temporary backward compatibility flag under JDK-8192936 and was immediately
> marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire
> in JDK 27.
>
> TBD: Need to submit a related CSR.
>
>
On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong wrote:
>> Hi @eme64 , could you please help take a look at this patch especially the
>> test part since most of the tests are SLP related? It will be helpful if you
>> could also help trigger a testing for it. Thanks for your time!
>
>> @XiaohongG
On Wed, 9 Jul 2025 10:43:07 GMT, Bhavana Kilambi wrote:
> Thanks for making the changes. Looks good to me.
Thanks a lot for your review!
-
PR Comment: https://git.openjdk.org/jdk/pull/26057#issuecomment-3054908101
The VM option -XX:AllowRedefinitionToAddDeleteMethods was added in JDK 13 as a
temporary backward compatibility flag under JDK-8192936 and was immediately
marked as Deprecate. The fix is to obsolete this option in JDK 26 and expire in
JDK 27.
There are two concerns which may require some negoti
> Adding SUADD an associative operation in the Vector API. Saturated addition
> on fixed-width unsigned integers is provably associative.
Ian Graves has updated the pull request incrementally with one additional
commit since the last revision:
Adding masked associative tests
-
C
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Expand test coverage of File methods
-
Changes:
- all:
Currently, DirectCodeBuilder is erroneously missing argument checks for a few
of its override methods that take arguments such as Opcode and the array size
for multianewarray and the switches, which would write something before
throwing an exception. We correct these problems and verify with som
On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote:
>> 8360122: Refine formatting of Connection.java interface
>>
>> -
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1
>> [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not con
On Fri, 9 May 2025 17:42:14 GMT, Benjamin Peterson wrote:
>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is
>> called on the target library file before it is passed to the system library
>> loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve
>
On Sun, 22 Jun 2025 01:13:26 GMT, simon wrote:
> 8360122: Refine formatting of Connection.java interface
>
> -
> ### Progress
> - [x] Change must be properly reviewed (1 review required, with at least 1
> [Reviewer](https://openjdk.org/bylaws#reviewer))
> - [x] Change must not contain e
On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote:
>> 8360122: Refine formatting of Connection.java interface
>>
>> -
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1
>> [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not con
On Wed, 9 Jul 2025 19:38:21 GMT, Chen Liang wrote:
>>> The changes are OK.
>>
>> Great, @LanceAndersen! Thanks for reviewing. 😃
>>
>> Can you integrate it when you think it is appropriate? I guess I do not have
>> permission to do it.
>
>> Can you integrate it when you think it is appropriate
On Wed, 9 Jul 2025 19:35:54 GMT, simon wrote:
> Can you integrate it when you think it is appropriate? I guess I do not have
> permission to do it.
They are done with GitHub comments parsed by bots, so if there is a line:
> /integrate
in a comment from you, the bot will integrate this patch (
On Wed, 9 Jul 2025 18:59:49 GMT, Lance Andersen wrote:
> The changes are OK.
Great, @LanceAndersen! Thanks for reviewing. 😃
Can you integrate it when you think it is appropriate? I guess I do not have
permission to do it.
-
PR Comment: https://git.openjdk.org/jdk/pull/25925#issu
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
> document th
Hi all,
This pull request contains a backport of commit
[c9bea773](https://github.com/openjdk/jdk/commit/c9bea77342672715f8f720d7311d66c2b3ac9f8a)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. #26200
The commit being backported was authored by Chen Liang on 9 Jul 2025 and was
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
> document th
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
> document th
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> modernizing the code by using List.of() is still a desirable improvement
except that `Collections.emptyList()` and `List.of()` unfortunately have
different tolerance to calls `List.indexOf(null)` and `List.contains(null)`.
-
PR
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Tue, 8 Jul 2025 20:45:20 GMT, simon wrote:
>> 8360122: Refine formatting of Connection.java interface
>>
>> -
>> ### Progress
>> - [x] Change must be properly reviewed (1 review required, with at least 1
>> [Reviewer](https://openjdk.org/bylaws#reviewer))
>> - [x] Change must not con
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
Replaced Collections.emptyList() with List.of() as part of refactoring. This
was discussed in the context of investigating a CDS-related issue
(https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14796714).
On Wed, 9 Jul 2025 18:16:44 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Clean up listFiles sub-test per suggestions
>
> test/jdk/java/io/File/EmptyPath.java line 216:
>
>> 214:
On Wed, 9 Jul 2025 18:22:51 GMT, Johannes Döbler wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Clean up listFiles sub-test per suggestions
>
> test/jdk/java/io/File/EmptyPath.java line 212:
>
>> 210
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Clean up listFiles sub-test per suggestions
-
Changes:
On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter wrote:
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
test/jdk/java/io/File/EmptyPath.java line 212:
> 210: File[] files = f.listFiles();
> 211: for (File file : files)
> 212
On Wed, 9 Jul 2025 12:11:10 GMT, Darragh Conway wrote:
>> test/jdk/java/io/File/MaxPathLength.java line 202:
>>
>>> 200: testLongPath (20, name, false);
>>> 201: testLongPath (20, name, true);
>>> 202: name = getNextName(name);
>>
>> Name doesn't
On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter wrote:
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
test/jdk/java/io/File/EmptyPath.java line 216:
> 214: List ioNames =
> 215: Arrays.asList(files).stream().map(f ->
Changes to address `File.listFiles` invoked on an empty path. This fixes an
oversight in #22821.
-
Commit messages:
- 8361587: AssertionError in File.listFiles() when path is empty and -esa is
enabled
Changes: https://git.openjdk.org/jdk/pull/26224/files
Webrev: https://webrevs.
On Wed, 9 Jul 2025 09:01:00 GMT, Alan Bateman wrote:
> > Testing: tier1 + jdk/jdk/jfr
>
> The tests for this area are in tier2 (not tier1).
I ran tier2. It was fine.
-
PR Comment: https://git.openjdk.org/jdk/pull/26210#issuecomment-3053405518
On Wed, 9 Jul 2025 13:25:22 GMT, Chen Liang wrote:
>> I have updated this patch to avoid a redundant `runtimeSetup` annotation -
>> we have agreed that the requirement for setup is a side effect of
>> initialization, and such methods in AOTCI classes must be automatically
>> recognized. This l
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
>
On Tue, 8 Jul 2025 16:10:17 GMT, Darragh Conway wrote:
> Refactored extract method to encapsulate Windows specific test logic
Looks good, just a minor comment
test/jdk/java/io/File/MaxPathLength.java line 200:
> 198: String name = fileName;
> 199: while (name.length() <
On Tue, 8 Jul 2025 16:34:47 GMT, Mikhail Yankelevich
wrote:
>> Refactored extract method to encapsulate Windows specific test logic
>
> test/jdk/java/io/File/MaxPathLength.java line 200:
>
>> 198: String name = fileName;
>> 199: while (name.length() < MAX_LENGTH) {
>> 20
Refactored extract method to encapsulate Windows specific test logic
-
Commit messages:
- 8360411:[TEST] open/test/jdk/java/io/File/MaxPathLength.java Refactor
extract method to encapsulate Windows specific
Changes: https://git.openjdk.org/jdk/pull/26193/files
Webrev: https://web
On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote:
> Please review this patch to add a new test to check `@since` tags in the
> `jdk.editpad` module.
>
> TIA
This pull request has now been integrated.
Changeset: 7daf9813
Author:Nizar Benalla
URL:
https://git.openjdk.org/jdk/com
On Tue, 3 Jun 2025 10:09:44 GMT, Nizar Benalla wrote:
> Please review this patch to add a new test to check `@since` tags in the
> `jdk.editpad` module.
>
> TIA
Thanks for the review Jaikiran. This passes on all platforms in our CI
-
PR Comment: https://git.openjdk.org/jdk/pull/2
On Wed, 9 Jul 2025 09:01:52 GMT, Alan Bateman wrote:
> I think we'll need to see if a test can be added as it's way too easy to
> refactor this code and re-introduce the issue.
I'm planning a follow-up PR that will check the top frame. Here's the draft:
https://github.com/openjdk/jdk/pull/26211
> I have updated this patch to avoid a redundant `runtimeSetup` annotation - we
> have agreed that the requirement for setup is a side effect of
> initialization, and such methods in AOTCI classes must be automatically
> recognized. This latest revision implements that model.
>
> I intentionall
Hi Ben,
Glad to hear that you were able to construct a custom Gatherer which meets your
needs!
Cheers,
√
Viktor Klang
Software Architect, Java Platform Group
Oracle
From: Jige Yu
Sent: Tuesday, 1 July 2025 06:55
To: Viktor Klang
Cc: core-libs-dev@openjdk.org
On Wed, 9 Jul 2025 09:17:13 GMT, Xiaohong Gong wrote:
>> Hi @eme64 , could you please help take a look at this patch especially the
>> test part since most of the tests are SLP related? It will be helpful if you
>> could also help trigger a testing for it. Thanks for your time!
>
>> @XiaohongG
On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
On Tue, 8 Jul 2025 20:28:23 GMT, Chen Liang wrote:
>> In the `class` file format, a lot of the values are `u1` or `u2`; the
>> Class-File API consistently model them with `int`. However, the API does
>> not, in general, validate that int values passed to the factory methods are
>> not out of t
On Tue, 8 Jul 2025 18:46:00 GMT, Chen Liang wrote:
> In a recent inspection of all methods that accept an `int` argument in the
> Class-File API, I noticed this method that validates its argument but did not
> document the validation. The behavior is to throw IOOBE. We can simply
> document th
On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Disable auto-vectorization of double to short conversion for NEON and
>> update tests
>
> Hi @eme64 , could you pleas
On Wed, 9 Jul 2025 09:06:44 GMT, Xiaohong Gong wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Disable auto-vectorization of double to short conversion for NEON and
>> update tests
>
> Hi @eme64 , could you pleas
On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
On Wed, 9 Jul 2025 05:45:01 GMT, Erik Gahlin wrote:
> Testing: tier1 + jdk/jdk/jfr
The tests for this area are in tier2 (not tier1).
I think we'll need to see if a test can be added as it's way too easy to
refactor this code and re-introduce the issue.
-
PR Comment: https://git.o
On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
Could I have a review of the change that prevents RandomAccessFile::readLine
from emitting an event per character? This leads to unnecessary overhead, both
with or without JFR enabled.
Testing: tier1 + jdk/jdk/jfr
Thanks
Erik
-
Commit messages:
- Remove mistakenly added file
- I
55 matches
Mail list logo
