On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote:
> Please review this fairly simple change to improve how the
> `JimageDiffGenerator` works. The original implementation is pretty naive and
> read all bytes into memory and then compared them. This improved version only
> reads bytes on
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of
> [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.)
>
> The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and
> was reviewed by Amit Kumar, Alex
On Tue, 17 Dec 2024 07:49:31 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [458979d8](https://github.com/openjdk/jdk/commit/458979d83ac784273263b54516369d79764010dd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Thu, 19 Dec 2024 12:38:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Sat, 7 Dec 2024 07:29:05 GMT, liyazzi wrote:
> For two cases:
>
> 1. When the ImageReaderFactory was loaded by local jdk,that means the
> ImageReaderFactory was loaded by boot class loader,then init the `Path
> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which is
>
Can I please get a review for this change which proposes to fix the issue noted
in https://bugs.openjdk.org/browse/JDK-8302293?
As noted in the issue, when creating a temporary file during the "jar --create"
operation, if the original file name is lesser than 3 characters, the temporary
file cr
On Thu, 19 Dec 2024 18:16:47 GMT, Severin Gehwolf wrote:
> @MBaesken @RealFYang Could you please test this PR since you originally ran
> into JDK-8346239 (this bug) and
> [JDK-8344036](https://bugs.openjdk.org/browse/JDK-8344036). Thanks!
Yes, I can confirm that it works on my linux-aarch64 pl
On Thu, 19 Dec 2024 21:30:10 GMT, Severin Gehwolf wrote:
>> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH`
>> without explicit `--module-path` option or a non-existent module path. In
>> addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and
>>
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of
> [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.)
>
> The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and
> was reviewed by Amit Kumar, Alex
On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote:
> When the static launcher was introduced in
> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
> resource constraints, it was only working properly on Linux and macOS, while
> the Windows port compiled but
Clarifying the documentation of `DateTimeFormatterBuilder.appendZoneId()` and
similar methods to align the description with the behavior, in which
`ZoneOffset` is only parsed from the formatter for offset texts without any
prefixes. Corresponding CSR has also been drafted.
-
Commit
On Mon, 16 Dec 2024 23:15:11 GMT, Justin Lu wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [fd0207d5](https://github.com/openjdk/jdk/commit/fd0207d59309ae1af9539580f5bfcbc7627789cb)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being
On Thu, 19 Dec 2024 16:48:33 GMT, Nizar Benalla wrote:
> Please review this doc-only patch to fix an issue that causes the
> cmp-baseline build to fail.
>
> The snippet in `LabelTrget.java` showed a highly rare non deterministism in
> javadoc snippet generation, which will be fixed in
> [JDK-
On Thu, 19 Dec 2024 16:27:30 GMT, Magnus Ihse Bursie wrote:
> We need to raise the abstraction of the SetupBuildLauncher API, to prepare
> for static launchers. We should specify the desired outcome, not what flags
> we should add. This can be seen as the last part of
> [JDK-8141444](https://b
On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote:
> When the static launcher was introduced in
> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
> resource constraints, it was only working properly on Linux and macOS, while
> the Windows port compiled but
On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote:
> When the static launcher was introduced in
> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
> resource constraints, it was only working properly on Linux and macOS, while
> the Windows port compiled but
On Fri, 20 Sep 2024 00:33:39 GMT, Weijun Wang wrote:
> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which
> sounds redundant, just say "expected not equals but was 12345".
>
> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...".
> Modify it to follow
On Thu, 19 Dec 2024 16:48:33 GMT, Nizar Benalla wrote:
> Please review this doc-only patch to fix an issue that causes the
> cmp-baseline build to fail.
>
> The snippet in `LabelTrget.java` showed a highly rare non deterministism in
> javadoc snippet generation, which will be fixed in
> [JDK-
On Thu, 19 Dec 2024 17:11:19 GMT, Mandy Chung wrote:
> Looks good. Please update the copyright end year.
Thanks for the review! Done in the latest update.
-
PR Comment: https://git.openjdk.org/jdk/pull/22494#issuecomment-2555803350
> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH`
> without explicit `--module-path` option or a non-existent module path. In
> addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and
> `--limit-modules` are used in combination. It failed earlier an
On Tue, 17 Dec 2024 15:41:51 GMT, Magnus Ihse Bursie wrote:
> When the static launcher was introduced in
> [JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
> resource constraints, it was only working properly on Linux and macOS, while
> the Windows port compiled but
When the static launcher was introduced in
[JDK-8339480](https://bugs.openjdk.org/browse/JDK-8339480), due to time and
resource constraints, it was only working properly on Linux and macOS, while
the Windows port compiled but did not work. Now the time has come to fix that.
Most of the changes
We need to raise the abstraction of the SetupBuildLauncher API, to prepare for
static launchers. We should specify the desired outcome, not what flags we
should add. This can be seen as the last part of
[JDK-8141444](https://bugs.openjdk.org/browse/JDK-8141444) (9 years later).
In the process,
On Thu, 19 Dec 2024 16:59:21 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Don't allow --limit-modules with ALL-MODULE-PATH
>
> test/jdk/tools/jlink/basic/AllModulePath.java line 133:
>
>> 13
On Tue, 17 Dec 2024 17:57:02 GMT, Martin Balao wrote:
>> In addition to the goals, scope, motivation, specification and requirement
>> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we
>> would like to describe the most relevant decisions taken during the
>> implementatio
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of
> [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.)
>
> The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and
> was reviewed by Amit Kumar, Alex
On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote:
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
The `Files.exists(Path.of(""))` case returns `t
On Thu, 19 Dec 2024 12:33:40 GMT, Weijun Wang wrote:
>> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which
>> sounds redundant, just say "expected not equals but was 12345".
>>
>> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...".
>> Modify it to f
On Thu, 19 Dec 2024 12:26:12 GMT, Weijun Wang wrote:
>> test/lib/jdk/test/lib/Asserts.java line 448:
>>
>>> 446: if ((unexpected == actual) || (unexpected != null &&
>>> unexpected.equals(actual))) {
>>> 447: msg = Objects.toString(msg, "assertNotEquals")
>>> 448:
On Thu, 12 Dec 2024 03:58:29 GMT, Erik Gahlin wrote:
>> We need to help Tim on the question of whether there is one or two events.
>>
>> An application that makes outbound network connections may run slowly for
>> several reasons. A duration event may help to diagnose this, irrespective of
>>
> This PR split out large array/set construction into separate factory methods
> to avoid oversized method trying to construct several of those.
>
> In order to do that, we will need to generate those help methods on demand in
> the class builder. Here we have two approach, one is for dedup set,
On Thu, 19 Dec 2024 17:26:50 GMT, Nizar Benalla wrote:
>> Please review this doc-only patch to avoid some unwanted failures in our
>> HTML checks.
>>
>> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
>> there trips some of our tests that use html validators (html-tidy
On Thu, 19 Dec 2024 17:26:50 GMT, Nizar Benalla wrote:
>> Please review this doc-only patch to avoid some unwanted failures in our
>> HTML checks.
>>
>> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
>> there trips some of our tests that use html validators (html-tidy
On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote:
> Please review this fairly simple change to improve how the
> `JimageDiffGenerator` works. The original implementation is pretty naive and
> read all bytes into memory and then compared them. This improved version only
> reads bytes on
Please review this fairly simple change to improve how the
`JimageDiffGenerator` works. The original implementation is pretty naive and
read all bytes into memory and then compared them. This improved version only
reads bytes on a bound buffer into memory compares those bytes and if equal
conti
On Thu, 19 Dec 2024 17:26:50 GMT, Nizar Benalla wrote:
>> Please review this doc-only patch to avoid some unwanted failures in our
>> HTML checks.
>>
>> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
>> there trips some of our tests that use html validators (html-tidy
On Thu, 19 Dec 2024 09:48:23 GMT, Per Minborg wrote:
> This PR proposes to improve the current `MemorySegment.toString()` method
> from:
>
> `MemorySegment{ address: 0x6264c540, byteSize: 8 }`
>
> to
>
> `MemorySegment{ native, address: 0x6264c540, byteSize: 8, confined, not
> alive,
On Thu, 19 Dec 2024 17:17:54 GMT, Brian Burkhalter wrote:
> can you establish if this has always been the case
The same behavior obtains on macOS with JDK 1.8.
-
PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2555259837
> Please review this doc-only patch to avoid some unwanted failures in our HTML
> checks.
>
> Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
> there trips some of our tests that use html validators (html-tidy and some
> other tests). I believe you shouldn't have an `` i
On Thu, 19 Dec 2024 17:11:51 GMT, Alan Bateman wrote:
> Path.of("") does exist
jshell> Files.exists(Path.of(""))
$1 ==> true
Indeed that is a contradiction.
-
PR Comment: https://git.openjdk.org/jdk/pull/22821#issuecomment-2555226465
On Thu, 19 Dec 2024 17:11:51 GMT, Alan Bateman wrote:
> [...] can you establish if this has always been the case and on all platforms?
It is the same on macOS and presumably other Unix variants where the `access`
system call will always fail for `""`. I have not checked older versions.
---
On Thu, 19 Dec 2024 16:48:33 GMT, Nizar Benalla wrote:
> Please review this doc-only patch to fix an issue that causes the
> cmp-baseline build to fail.
>
> The snippet in `LabelTrget.java` showed a highly rare non deterministism in
> javadoc snippet generation, which will be fixed in
> [JDK-
On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote:
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
This is surprising, can you establish if this h
On Thu, 19 Dec 2024 11:10:16 GMT, Severin Gehwolf wrote:
>> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH`
>> without explicit `--module-path` option or a non-existent module path. In
>> addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and
>>
Please review this doc-only patch to avoid some unwanted failures in our HTML
checks.
Javadoc wraps everything under `@param` in a ``, so having an `h2` tag
there trips some of our tests that use html validators (html-tidy and some
other tests). I believe you shouldn't have an `` inside of a s
On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote:
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
Marked as reviewed by lancea (Reviewer).
Marke
On Thu, 19 Dec 2024 00:36:44 GMT, Brian Burkhalter wrote:
> Update the specification of `java.io.File.exists()` to match its behavior,
> which seems correct in the context of how the empty abstract pathname is
> documented elsewhere in the class.
lgtm
-
Marked as reviewed by rrig
Please review this doc-only patch to fix an issue that causes the cmp-baseline
build to fail.
The snippet in `LabelTrget.java` showed a highly rare non deterministism in
javadoc snippet generation, which will be fixed in
[JDK-8346659](https://bugs.openjdk.org/browse/JDK-8346659), but we can fix
On Tue, 17 Dec 2024 17:57:02 GMT, Martin Balao wrote:
>> In addition to the goals, scope, motivation, specification and requirement
>> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we
>> would like to describe the most relevant decisions taken during the
>> implementatio
On Thu, 19 Dec 2024 12:38:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Tue, 17 Dec 2024 07:49:31 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [458979d8](https://github.com/openjdk/jdk/commit/458979d83ac784273263b54516369d79764010dd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Tue, 17 Dec 2024 07:49:31 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [458979d8](https://github.com/openjdk/jdk/commit/458979d83ac784273263b54516369d79764010dd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Tue, 17 Dec 2024 08:04:25 GMT, Sorna Sarathi N wrote:
> Hi all,
>
> This pull request contains a backport of
> [openjdk/jdk#22704](https://github.com/openjdk/jdk/pull/22704.)
>
> The commit being backported was authored by Sorna Sarathi on 13 Dec 2024 and
> was reviewed by Amit Kumar, Alex
On Thu, 19 Dec 2024 12:38:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Thu, 19 Dec 2024 13:50:32 GMT, Per Minborg wrote:
>> src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line
>> 34:
>>
>>> 32: import java.util.List;
>>> 33:
>>> 34: import jdk.internal.foreign.FunctionDescriptorImpl;
>>
>> Just curious where this style/convention is com
On Thu, 19 Dec 2024 13:26:29 GMT, Alan Bateman wrote:
>> This PR proposes to clean up all the imports in the FFM lib (excluding
>> tests).
>>
>> Passes tier1-tier3
>
> src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 34:
>
>> 32: import java.util.List;
>> 33:
>> 34:
On Thu, 19 Dec 2024 10:46:03 GMT, Per Minborg wrote:
> This PR proposes to clean up all the imports in the FFM lib (excluding tests).
>
> Passes tier1-tier3
src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 34:
> 32: import java.util.List;
> 33:
> 34: import jdk.inter
On Thu, 19 Dec 2024 12:38:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Thu, 19 Dec 2024 12:35:39 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Thu, 19 Dec 2024 11:46:36 GMT, Alan Bateman wrote:
> I'm happy with the current changes in the PR. The copyright header date in
> ImageReaderFactory can be updated to 2024, and the import of Disabled can be
> removed from the SetDefaultProvider test.
>
> To your question about tests then it
On Thu, 19 Dec 2024 12:33:50 GMT, Alan Bateman wrote:
>> liyazzi has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update the date of 'ImageReaderFactory'
>> - Update the date of 'ImageReaderFactory' and remove the import of
>> 'Disabl
> For two cases:
>
> 1. When the ImageReaderFactory was loaded by local jdk,that means the
> ImageReaderFactory was loaded by boot class loader,then init the `Path
> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which is
> obtained through reflection,due to it is in jdk i
On Thu, 19 Dec 2024 10:17:28 GMT, Daniel Jeliński wrote:
>> test/lib/jdk/test/lib/Asserts.java line 256:
>>
>>> 254: * @see #assertNotEqualsByteArray(byte[], byte[], String)
>>> 255: */
>>> 256: public static void assertNotEqualsByteArray(byte[] unexpected,
>>> byte[] actual) {
>>
On Thu, 19 Dec 2024 03:50:59 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> be precise in method spec
>
> test/lib/jdk/test/lib/Asserts.java line 448:
>
>> 446: if ((unexpected == actual)
> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which
> sounds redundant, just say "expected not equals but was 12345".
>
> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...".
> Modify it to follow the `assertEquals` style ""expected... but was...".
W
On Thu, 19 Dec 2024 03:19:35 GMT, Valerie Peng wrote:
>> Correct, I'll fix.
>>
>> As for its usages (in `ML_KEM_Test.java` etc), I'll be happy to fix them. In
>> fact, I first noticed those inconsistency and then decided to make the
>> changes here. Would you prefer them to be fixed in this PR
On Thu, 19 Dec 2024 09:23:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
On Wed, 18 Dec 2024 19:11:12 GMT, Severin Gehwolf wrote:
>> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH`
>> without explicit `--module-path` option or a non-existent module path. In
>> addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and
>>
> Please review this extension to #22609 which now disallows `ALL-MODULE-PATH`
> without explicit `--module-path` option or a non-existent module path. In
> addition, this fixes a bug mentioned in #22609 when `ALL-MODULE-PATH` and
> `--limit-modules` are used in combination. It failed earlier an
This PR proposes to clean up all the imports in the FFM lib (excluding tests).
-
Commit messages:
- Fix imports
Changes: https://git.openjdk.org/jdk/pull/22827/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22827&range=00
Issue: https://bugs.openjdk.org/browse/JDK-834661
On Thu, 19 Dec 2024 03:33:43 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> be precise in method spec
>
> test/lib/jdk/test/lib/Asserts.java line 256:
>
>> 254: * @see #assertNotEqualsByteAr
This PR proposes to improve the current `MemorySegment.toString()` method from:
`MemorySegment{ address: 0x6264c540, byteSize: 8 }`
to
`MemorySegment{ native, address: 0x6264c540, byteSize: 8, confined, not
alive, read-only, mapped }`
Tests passes tier1-tier3
-
Commit mes
On Thu, 19 Dec 2024 09:23:27 GMT, liyazzi wrote:
>> For two cases:
>>
>> 1. When the ImageReaderFactory was loaded by local jdk,that means the
>> ImageReaderFactory was loaded by boot class loader,then init the `Path
>> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which
> For two cases:
>
> 1. When the ImageReaderFactory was loaded by local jdk,that means the
> ImageReaderFactory was loaded by boot class loader,then init the `Path
> BOOT_MODULES_JIMAGE` by using `sun.nio.fs.DefaultFileSystemProvider` which is
> obtained through reflection,due to it is in jdk i
On Tue, 17 Dec 2024 11:09:09 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
> This PR split out large array/set construction into separate factory methods
> to avoid oversized method trying to construct several of those.
>
> In order to do that, we will need to generate those help methods on demand in
> the class builder. Here we have two approach, one is for dedup set,
On Wed, 18 Dec 2024 08:27:09 GMT, liyazzi wrote:
>> The test change means this test ends up with two copies of the test
>> provider. I'll create an issue in JBS to refactor this test to allow it be
>> used for all cases (class path, module path, linked into run-time image).
>> That would make
77 matches
Mail list logo
