Please review the application of the `@Serial` annotation
([JDK-8202385](https://bugs.openjdk.org/browse/JDK-8202385)) to types in the
java.logging module to enable stricter compile-time checking of
serialization-related declarations. Only one class remains to be covered; all
other relevant fie
On Fri, 6 Jun 2025 18:35:53 GMT, Phil Race wrote:
> The fix for JDK-8344235: Revisit SecurityManager usage in java.logging after
> JEP 486 and JEP 491 integration
> removed use of AppContext from java/util/logging/LogManager.java.
> That was the only place in the JDK that used
> jdk.internal.ac
On Wed, 21 May 2025 00:59:34 GMT, Sergey Bylokhov wrote:
> Both fields were added by the
> [JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
> see
> https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
> And the usage were deleted by the
Both fields were added by the
[JDK-4851777](https://bugs.openjdk.org/browse/JDK-4851777):
see
https://github.com/openjdk/jdk/commit/4045a8be07195acac7fb2faef0e6bf90edcaf9f8
And the usage were deleted by the
[JDK-8341402](https://bugs.openjdk.org/browse/JDK-8341402):
see
https://github.com/openj
On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato wrote:
>> For the l10n files, they are synced by the translation team and we don't
>> edit them. IMO, I think it's fine leaving those ones as is. Especially
>> because language rules can cause different spacing and punctuation
>> characters, so gene
On Wed, 14 May 2025 06:32:30 GMT, Magnus Ihse Bursie wrote:
> That seems reasonable, yes. However, I'd like to keep this change to the
> absolute minimum. Feel free to open a separate issue for fixing this.
FIled: https://bugs.openjdk.org/browse/JDK-8356937
-
PR Review Comment: ht
On Fri, 9 May 2025 14:14:57 GMT, Magnus Ihse Bursie wrote:
> A handful of html and xml files in the JDK source tree claims to have
> encodings like `ISO-8859-1`, when they are in fact pure US-ASCII files.
>
> While perhaps technically correct, this is misleading, and goes contrary to
> the eff
On Tue, 29 Apr 2025 07:11:30 GMT, Per Minborg wrote:
> In the end, this didn't make the bar in terms of cost/benefit. For example,
> backporting might be impacted.
The first LTS release to include this API will be 25, correct? It would be best
to clean this up in advance, as backporting to ver
On Wed, 19 Feb 2025 09:22:09 GMT, Per Minborg wrote:
> This PR proposes to make all imports consistent in the FFM API tests and
> benchmarks.
>
> This is a follow-up PR from https://github.com/openjdk/jdk/pull/22827
>
> Passes tier1-3
test/jdk/java/foreign/TestFunctionDescriptor.java line 38:
On Thu, 9 Jan 2025 11:47:15 GMT, Per Minborg wrote:
>> This PR proposes to clean up all the imports in the FFM lib (excluding
>> tests).
>>
>> Passes tier1-tier3
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes th
On Mon, 14 Apr 2025 12:53:35 GMT, Magnus Ihse Bursie wrote:
>> Most of the JDK code base has been transitioned to UTF-8, but not all. This
>> has recently become an acute problem, since our mixing of iso-8859-1 and
>> utf-8 in properties files confused the version of `sed` that is shipped with
On Thu, 10 Apr 2025 10:10:49 GMT, Magnus Ihse Bursie wrote:
> I have checked the entire code base for incorrect encodings, but luckily
> enough these were the only remaining problems I found.
>
> BOM (byte-order mark) is a method used for distinguishing big and little
> endian UTF-16 encoding
On Thu, 14 Nov 2024 23:51:24 GMT, Phil Race wrote:
> remove uses of SM APIs from the java.datatransfer module. Also cleans up the
> now un-needed export from java.base
Marked as reviewed by serb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/22127#pullrequestreview-2437
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote:
>> There is some old awt/2d coding where warnings occur when running with ubsan
>> enabled binaries.
>> However at most of these locations the coding should work (at least on our
>> supported platform set) so the warnings can be disabled
On Mon, 22 Jan 2024 20:52:32 GMT, Roger Riggs wrote:
> When an exception handler for an OutOfMemoryError uses string concatenation
> to compose an exception message, the invoke dynamic string format
> implementation may itself exhaust memory, preventing the exception from being
> handled.
> Ex
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
This pull request has now been integrated.
Changeset: 5cf794
On Fri, 12 Jan 2024 07:22:09 GMT, Alan Bateman wrote:
> Just curious if this was found by inspection or when debugging some issue
> with LDAP authentication? Asking on whether it is feasible or not to have
> more tests in this area.
It was found by the code inspection.
-
PR Comme
SaslInputStream.read() should return a value in the range from 0 to 255 per the
spec of InputStream.read() but it returns the signed byte from the inBuf as is.
-
Commit messages:
- 8323562: SaslInputStream.read() may return wrong value
Changes: https://git.openjdk.org/jdk/pull/1736
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
I'll wait until GA will be fixed.
-
PR
On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race wrote:
>> Many printing tests do not have the @printer keyword. This adds them to
>> those that need it.
>> I also found one test that has nothing to do with printing in the print
>> folder and moved it out.
>
> Phil Race has updated the pull request
On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race wrote:
>> Many printing tests do not have the @printer keyword. This adds them to
>> those that need it.
>> I also found one test that has nothing to do with printing in the print
>> folder and moved it out.
>
> Phil Race has updated the pull request
On Tue, 7 Nov 2023 00:37:47 GMT, Phil Race wrote:
> > > So we have somewhere around a fixed 125ms startup cost for the FFM case -
> > > as measured on my Mac,
> > > but only 35-40ms of that is attributable to the specific needs of layout.
> >
> >
> > That looks unfortunate. I guess if we will
On Mon, 13 Nov 2023 12:51:36 GMT, Jorn Vernee wrote:
>> Add the ability to pass heap segments to native code. This requires using
>> `Linker.Option.critical(true)` as a linker option. It has the same
>> limitations as normal critical calls, namely: upcalls into Java are not
>> allowed, and the
On Mon, 13 Nov 2023 12:51:36 GMT, Jorn Vernee wrote:
>> Add the ability to pass heap segments to native code. This requires using
>> `Linker.Option.critical(true)` as a linker option. It has the same
>> limitations as normal critical calls, namely: upcalls into Java are not
>> allowed, and the
On Mon, 6 Nov 2023 23:28:30 GMT, Phil Race wrote:
>So we have somewhere around a fixed 125ms startup cost for the FFM case - as
>measured on my Mac,
but only 35-40ms of that is attributable to the specific needs of layout.
That looks unfortunate. I guess if we will start to use ffm in other pla
On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race wrote:
>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional
> commit since the last revision:
>
> indentation
Since we plan to import it into jdk22, do
On Fri, 1 Sep 2023 03:45:24 GMT, Phil Race wrote:
> Probably I should not have posted this PR even as draft if it is going to get
> attention as it isn't really ready for that.
No! That is really interesting proposal and discussion!
BTW this PR is not in the draft state.
-
PR Com
On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race wrote:
> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
@prrace did you check how this change affects the performance, especially
startup? I have experimented with Panama for littlecms:
https://bugs.openjdk.org/browse/JDK-831334
On Sat, 9 Sep 2023 14:33:53 GMT, Lance Andersen wrote:
> Please review this PR which improves the Zip64 extra header validation:
>
> - Throw a ZipException If the extra len field is 0 and :
> -- size, csize, or loc offset are set to 0x
> -- disk starting number is set to 0x
>
> - We
On Fri, 18 Aug 2023 17:25:10 GMT, Ben Taylor wrote:
> Backport is clean, all tests in test/jdk/java/util/zip pass.
It is strange that there is a request for jdk21u but there is no PR for that
repo.
-
PR Comment: https://git.openjdk.org/jdk21/pull/173#issuecomment-1684250803
On Wed, 16 Aug 2023 15:36:53 GMT, Alan Bateman wrote:
>As I think has already been said, we can't engage with you in this PR on the
>reasons why additional checking was added in a security update.
I think you have an assumption that this check for exact size(8/16/24) bytes
are related to the c
On Wed, 16 Aug 2023 04:16:52 GMT, Sergey Bylokhov wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleaned up spacing and added missing comma
>
> My overall point is that it will b
On Tue, 15 Aug 2023 18:43:36 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when open
On Tue, 15 Aug 2023 23:13:00 GMT, Volker Simonis wrote:
>As far as I understand you can manually create "artificial" zip files which
>can be processed by the zip tool and previous versions of the JDK but not by
>new ones.
It can be processed by the new/latest version of JDK8.
> As long as the
On Tue, 15 Aug 2023 21:38:41 GMT, Volker Simonis wrote:
> Did you create that zip file manually or was it created by a tool and if by a
> tool than which one? I think we must differentiate here between functional
> compatibility with a tool like "zip", compatibility with a specification and
>
On Tue, 15 Aug 2023 17:56:09 GMT, Volker Simonis wrote:
>This seems to be a very "free" interpretation of the specification to me.
>According to my understanding, the valid sizes of 8, 16, 24 or 28 as described
>in the Wikipedia article are a direct consequence of the specification.
I have pro
On Tue, 15 Aug 2023 10:49:37 GMT, Alan Bateman wrote:
> Are you arguing to drop all checking of the extra fields? It's not clear to
> me that this PR should be do that as it has a lot of implications.
Not all, but do it in a different way. The only thing which is MUST be
implemented according
On Mon, 14 Aug 2023 21:21:30 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when open
On Mon, 14 Aug 2023 20:28:08 GMT, Lance Andersen wrote:
> > net/n3/nanoxml/CDATAReader.class bad extra-field entry:
> > EF block length (61373 bytes) exceeds remaining EF data (4 bytes)
> > test of bad.jar FAILED
> > zip error: Zip file invalid, could not spawn unzip, or wrong unzip
> > (origina
On Mon, 14 Aug 2023 18:41:26 GMT, Sergey Bylokhov wrote:
> > I am not understanding your point. There is a specific order for the Zip64
> > fields based on which fields have the Magic value. the spec does also not
> > suggest that an empty Zip64 extra field can be writt
On Mon, 14 Aug 2023 18:22:27 GMT, Lance Andersen wrote:
>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 3108:
>>
>>> 3106: break;
>>> 3107: }
>>> 3108: if (size == ZIP64_MINVAL) {
>>
>> Note that we always incr
On Mon, 14 Aug 2023 18:32:15 GMT, Lance Andersen wrote:
>I am not understanding your point. There is a specific order for the Zip64
>fields based on which fields have the Magic value. the spec does also not
>suggest that an empty Zip64 extra field can be written to the CEN when there
>is a Zip
On Mon, 14 Aug 2023 17:33:30 GMT, Lance Andersen wrote:
>> This PR updates the extra field validation added as part of
>> [JDK-8302483](https://bugs.openjdk.org/browse/JDK-8302483) to deal with
>> issues seen with 3rd party tools/libraries where a ZipException may be
>> encountered when open
On Mon, 14 Aug 2023 17:16:36 GMT, Alan Bateman wrote:
> It's unfortunate that there are tools and plugins in the eco system that have
> these issues. I think you've got the right balance here, meaning tolerating a
> zip64 extra block with a block size of 0 and rejecting corrupted extra blocks
On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov wrote:
> This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
> problem list for linux-x86 where it intermittently fails on a GA, ex:
> https://github.com/openjdk/jdk21/pull/148
>
> This is only for JDK 21,
On Thu, 27 Jul 2023 18:21:45 GMT, Sergey Bylokhov wrote:
> This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
> problem list for linux-x86 where it intermittently fails on a GA, ex:
> https://github.com/openjdk/jdk21/pull/148
>
> This is only for JDK 21,
This patch adds the java/lang/ScopedValue/StressStackOverflow.java to the
problem list for linux-x86 where it intermittently fails on a GA, ex:
https://github.com/openjdk/jdk21/pull/148
This is only for JDK 21, test passes on JDK 22.
-
Commit messages:
- use linux-i586
- 8313260
On Tue, 25 Jul 2023 23:51:34 GMT, Sergey Bylokhov wrote:
>> Julian Waters 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
On Thu, 13 Oct 2022 14:48:29 GMT, Julian Waters wrote:
>> The C99 snprintf is available with Visual Studio 2015 and above, alongside
>> Windows 10 and the UCRT, and is no longer identical to the outdated Windows
>> _snprintf. Since support for the Visual C++ 2017 compiler was removed a
>> whil
On Thu, 13 Oct 2022 14:34:25 GMT, Julian Waters wrote:
>> Looks good. Thanks.
>
> @dholmes-ora could I trouble you for a sponsor? Thanks!
@TheShermanTanker Working on a similar cleanup, and wonder if is it correct to
assume that the "snprintf" adds "nul" even in case of error.
For example, this
On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato wrote:
>> Pleases review this PR.
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in
>> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
>> ar
On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato wrote:
> Pleases review this PR.
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in
> 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work
> around
On Sat, 21 Jan 2023 19:40:58 GMT, Sergey Bylokhov wrote:
> The next warning is fixed:
>
> === Output from failing command(s) repeated here ===
> * For target jdk_modules_java.base__the.java.base_batch:
This pull request has now been integrated.
Changeset: 3ea4eac1
Author:Ser
The next warning is fixed:
=== Output from failing command(s) repeated here ===
* For target jdk_modules_java.base__the.java.base_batch:
-
Commit messages:
- The build is broken after JDK-8294693
Changes: https://git.openjdk.org/jdk/pull/12129/files
Webrev: https://webrevs.openjd
On Sat, 21 Jan 2023 18:31:28 GMT, Tagir F. Valeev wrote:
>> Java 17 added RandomGenerator interface. However, existing method
>> Collections.shuffle accepts old java.util.Random class. While since Java 19,
>> it's possible to use Random.from(RandomGenerator) wrapper, it would be more
>> conven
On Wed, 18 Jan 2023 22:06:55 GMT, Tagir F. Valeev wrote:
>> Tagir F. Valeev has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains four commits:
>>
>> - Copyright year and @since tag updated
>> - Fixes according to review
>>
>>
On Sat, 21 Jan 2023 18:31:28 GMT, Tagir F. Valeev wrote:
>> Java 17 added RandomGenerator interface. However, existing method
>> Collections.shuffle accepts old java.util.Random class. While since Java 19,
>> it's possible to use Random.from(RandomGenerator) wrapper, it would be more
>> conven
On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg wrote:
>> Code in java.io contains many legacy constructs and semantics not
>> recommended including:
>>
>> * C-style array declaration
>> * Unnecessary visibility
>> * Redundant keywords in interfaces (e.g. public, static)
>> * Non-standard nam
On Tue, 10 Jan 2023 16:06:15 GMT, Per Minborg wrote:
>> Code in java.io contains many legacy constructs and semantics not
>> recommended including:
>>
>> * C-style array declaration
>> * Unnecessary visibility
>> * Redundant keywords in interfaces (e.g. public, static)
>> * Non-standard nam
On Mon, 9 Jan 2023 08:57:11 GMT, Per Minborg wrote:
>> Code in java.io contains many legacy constructs and semantics not
>> recommended including:
>>
>> * C-style array declaration
>> * Unnecessary visibility
>> * Redundant keywords in interfaces (e.g. public, static)
>> * Non-standard nami
On Mon, 9 Jan 2023 08:33:09 GMT, Viktor Klang wrote:
>> Currently Set.copyOf allocates both a HashSet and a new empty array when the
>> input collection is empty.
>>
>> This patch avoids allocating anything for the case where the parameter
>> collection's isEmpty returns true.
>
> Viktor Klang
On Wed, 4 Jan 2023 19:39:23 GMT, Stuart Marks wrote:
> so it's difficult to write a simple functional test for this change.
It is possible to track that for some "custom" and empty collection the only
method will be called is `isEmpty` and nothing else. Not sure how it is useful
or not.
-
On Thu, 22 Dec 2022 18:15:07 GMT, Harshitha Onkar wrote:
>> ViewportOverlapping was failing intermittently on Windows (Win10 & 11).
>> Added robot.setAutoWaitForIdle() to ViewportOverlapping and its base class
>> (OverlappingTestBase) to stabilize the test.
>>
>> Additionally added awt & swing
On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov wrote:
> The `java/lang/String/StringRepeat.java` test was updated twice after
> integration:
>
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the
> xmx2g
> https://bugs.openjdk.org/browse
On Tue, 13 Dec 2022 00:06:00 GMT, Sergey Bylokhov wrote:
> The `java/lang/String/StringRepeat.java` test was updated twice after
> integration:
>
> https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the
> xmx2g
> https://bugs.openjdk.org/browse
On Tue, 13 Dec 2022 07:58:36 GMT, Alan Bateman wrote:
> What you have looks okay if only Windows 32-bit is skipped but it might be
> simpler to just require sun.arch.data.model == "64" so that it only runs on
> 64-bit systems.
Right, but one of the fix for this test explicitly added support fo
On Tue, 13 Dec 2022 04:54:44 GMT, Jaikiran Pai wrote:
> Hello Sergey, the linked JBS issues note that this test takes at most 1400M.
> Should there be some investigation into why it's failing even with 2GB
> allowance?
On windows x86 java fails even before the start of the test, it is just
im
The `java/lang/String/StringRepeat.java` test was updated twice after
integration:
https://bugs.openjdk.org/browse/JDK-8221400 - the xmx4g was replaced by the
xmx2g
https://bugs.openjdk.org/browse/JDK-8265421 - the "os.maxMemory >= 2G" was added
Unfortunately, this test still may fail on Window
On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote:
> Newer version of IntelliJ IDEA introduces new
> [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases)
> detecting redundant array length check in snippets like
>
On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote:
> [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an
> attempt to remove all trailing whitespace from properties files, and enable a
> jcheck verification that they did not come back, similar to other source
>
On Mon, 28 Nov 2022 19:56:23 GMT, Sergey Bylokhov wrote:
>> src/java.base/share/classes/java/math/MutableBigInteger.java line 1536:
>>
>>> 1534:
>>> 1535: // Must insert leading 0 in rem if its length did not change
>>> 1536: if (rem.in
On Mon, 28 Nov 2022 19:49:55 GMT, Sergey Bylokhov wrote:
>> Remove redundant code reported in
>>
>> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 1536:
>
>> 1534:
On Mon, 28 Nov 2022 18:58:29 GMT, Joe Darcy wrote:
> Remove redundant code reported in
>
> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html
src/java.base/share/classes/java/math/MutableBigInteger.java line 1536:
> 1534:
> 1535: // Must insert leading 0 in rem
On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR includes changes in the resource bundle
> sources to follow the time zone change observed in America/Chihuahua and
> America/Ojinaga.
Looks fine
-
Marked as reviewed by serb (Reviewer).
PR: htt
On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote:
>> Hi all,
>>
>> As discussed here
>> https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it
>> would be better to add the vector api tests in GHA.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull reques
On Fri, 13 May 2022 01:54:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change to the build system which now makes
>> bundled zlib as the default for macos aarch64 systems?
>>
>> We have been running into various intermittent failures on macos aarch64
>> systems for several
76 matches
Mail list logo
