Re: RFR: 8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException [v2]

not checked > between reading the fields and invoking the constructor to create the record > or assigning the fields to an object being constructed. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add description of exception behavior wh

Re: RFR: 8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException

On Wed, 1 May 2024 18:43:21 GMT, Roger Riggs wrote: > The issue reported a ClassCastException "cannot assign instance of > java.util.CollSer to field of type java.util.Map" > while deserializing an object referring to an immutable Map that contained a >

Re: RFR: 8331224: ClassCastException in ObjectInputStream hides ClassNotFoundException

On Thu, 16 May 2024 21:18:04 GMT, Stuart Marks wrote: >> The issue reported a ClassCastException "cannot assign instance of >> java.util.CollSer to field of type java.util.Map" >> while deserializing an object referring to an immutable Map that contained a >> reference to a class that was not

Re: Deterministic naming of subclasses of `java/lang/reflect/Proxy`

be referenced by name, only as a capability, they can be better encapsulated. fyi, Roger Riggs On 5/16/24 8:11 AM, Aman Sharma wrote: Hi, Thanks for your response, Liang! > I think you meant CVE-2021-42392 instead of 2022. Sorry of the error. I indeed meant CVE-2021-42392 <

Re: RFR: 8331646: Add specific regression leap year tests [v5]

On Fri, 10 May 2024 09:22:39 GMT, serhiysachkov wrote: >> Calendar.add() tests that describe its behavior. > > serhiysachkov has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8331646 fixing typo A bit late but the descriptions of the

Re: RFR: JDK-8331646: Add specific regression leap year tests (Task - P4)

On Fri, 3 May 2024 10:31:14 GMT, serhiysachkov wrote: > Calendar.add() tests that describe its behavior. The bug report and/or the PR description should describe the change in more detail. What conditions of the Calendar spec are being tested. Thanks - PR Comment:

Re: RFR: 8330276: Console methods with explicit Locale [v2]

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato wrote: >> Proposing new overloaded methods in `java.io.Console` class that explicitly >> take a `Locale` argument. Existing methods rely on the default locale, so >> the users won't be able to format their prompts/outputs in a certain locale >>

Re: In support of Instant.minus(Instant)

Hi, I would also reinforce Stephen's early observation that the pattern for "until" methods in java.time includes those of the XXXDate classes, with a single Temporal parameter.  Period and Duration are similar values holding relative TemporalAmounts.     public Period until(ChronoLocalDate

Re: RFR: 8331202: Support for Duration until another Instant [v3]

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato wrote: >> A new method on Instant to return the duration `until` another Instant is >> suggested per the following discussion thread: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html >> >> A CSR has also been drafted. >

Re: RFR: 8331202: Support for Duration until another Instant [v3]

On Wed, 1 May 2024 17:21:20 GMT, Naoto Sato wrote: >> A new method on Instant to return the duration `until` another Instant is >> suggested per the following discussion thread: >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2024-April/122131.html >> >> A CSR has also been drafted. >

RFR: 8331224: ClassCastException in ObjectStreamClass during deserialization - cannot assign instance of java.util.CollSer to field of type java.util.Map

The issue reported a ClassCastException "cannot assign instance of java.util.CollSer to field of type java.util.Map" while deserializing an object referring to an immutable Map that contained a reference to a class that was not available. Immutable Collections such as Map utilize a serialization

Re: RFR: 8330276: Console methods with explicit Locale [v2]

On Mon, 29 Apr 2024 23:22:21 GMT, Naoto Sato wrote: >> Proposing new overloaded methods in `java.io.Console` class that explicitly >> take a `Locale` argument. Existing methods rely on the default locale, so >> the users won't be able to format their prompts/outputs in a certain locale >>

Re: In support of Instant.minus(Instant)

A constructive API enhancement. Created JDK-8331202 Support for duration between Instants Regards, Roger On 4/25/24 4:53 PM, Stephen Colebourne wrote: java.time.* already has the `until(ChronoLocalDate)` method on LocalDate. It would be

Integrated: 8329805: Deprecate for removal ObjectOutputStream.PutField.write

On Tue, 16 Apr 2024 19:44:36 GMT, Roger Riggs wrote: > The method `java.io.ObjectOutputStream.PutField.write` has been deprecated > since 1.4 and should be deprecated for removal. The Deprecation annotation is > updated to indicate the intention to remov the method. This pull reques

Re: RFR: 8330624: Inconsistent use of semicolon in the code snippet of java.io.Serializable javadoc

On Sat, 20 Apr 2024 11:49:30 GMT, Korov wrote: > Fix the description of java.io.Serializable. LGTM; trivial fix of example javadoc code - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18874#pullrequestreview-2022703632

Re: RFR: 8330802: Desugar switch in Locale::createLocale [v2]

On Mon, 22 Apr 2024 14:11:41 GMT, Claes Redestad wrote: >> This switch expression in `Locale::createLocale` is causing a somewhat large >> startup regression on my local system. Desugaring to if statements seem like >> the right thing to do while we investigate ways to further reduce overheads

Re: RFR: 8329760: Add indexOf(Predicate filter) to java..util.List interface [v9]

On Fri, 19 Apr 2024 12:59:24 GMT, Evemose wrote: >> **Subject** >> Addition of Predicate-based `indexOf` and `lastIndexOf` methods to >> `java.util.List` >> >> **Motivation** >> The motivation behind this proposal is to enhance the functionality of the >> `List` interface by providing a more

RFR: 8329805: Deprecate for removal ObjectOutputStream.PutField.write

The method `java.io.ObjectOutputStream.PutField.write` has been deprecated since 1.4 and should be deprecated for removal. The Deprecation annotation is updated to indicate the intention to remov the method. - Commit messages: - 8329805: Deprecate for removal

Re: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant [v3]

On Wed, 10 Apr 2024 16:17:32 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue >> noted in https://bugs.openjdk.org/browse/JDK-8212895? >> >> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is >> initialized to have a

Re: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant [v2]

On Tue, 9 Apr 2024 08:34:39 GMT, Jaikiran Pai wrote: >> Should `INSTANT_SECONDS("InstantSeconds", SECONDS, FOREVER, >> ValueRange.of(Instant.MIN.getEpochSecond(), Instant.MAX.getEpochSecond())), >> ` work? > > Hello Naoto, that's a very good point. I was too caught up with the constant >

Re: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant [v2]

On Tue, 9 Apr 2024 08:37:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the issue >> noted in https://bugs.openjdk.org/browse/JDK-8212895? >> >> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is >> initialized to have a

Re: RFR: 8212895: ChronoField.INSTANT_SECONDS's range doesn't match the range of Instant

On Mon, 8 Apr 2024 18:00:02 GMT, Naoto Sato wrote: >> Can I please get a review of this change which proposes to fix the issue >> noted in https://bugs.openjdk.org/browse/JDK-8212895? >> >> As noted in that issue, the `ChronoField.INSTANT_SECONDS` currently is >> initialized to have a minimum

Integrated: 8329623: NegativeArraySizeException encoding large String to UTF-8

On Fri, 5 Apr 2024 17:44:38 GMT, Roger Riggs wrote: > When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) > computation of the buffer size may exceed the range of a positive 32-bit > Integer. > If the estimated size for the result byte array is too large,

Re: RFR: 8329623: NegativeArraySizeException encoding large String to UTF-8

On Mon, 8 Apr 2024 13:39:34 GMT, Roger Riggs wrote: >> test/jdk/java/lang/String/CompactString/MaxSizeUTF16String.java line 143: >> >>> 141: // Strings of size min+1...min+2, throw OOME >>> 142: // The resulting byte array would exceed

Re: RFR: 8329623: NegativeArraySizeException encoding large String to UTF-8

On Mon, 8 Apr 2024 08:54:21 GMT, Raffaello Giulietti wrote: >> When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) >> computation of the buffer size may exceed the range of a positive 32-bit >> Integer. >> If the estimated size for the result byte array is too large,

Re: RFR: 8329623: NegativeArraySizeException encoding large String to UTF-8

On Fri, 5 Apr 2024 20:17:39 GMT, Naoto Sato wrote: > LGTM. The test case could be more thorough if it tests strings with > supplementary codepoints, as the new method computes them exclusively. I considered that, but the worst case is the x3 expansion. A 2 character high/low surrogate pair

RFR: 8329623: NegativeArraySizeException encoding large String to UTF-8

When encoding a vary large string in String.getBytes(StandardCharset.UTF_8) computation of the buffer size may exceed the range of a positive 32-bit Integer. If the estimated size for the result byte array is too large, pre-compute the exact buffer size. If that exceeds the range, then throw

Re: RFR: JDK-8329089: Empty immutable list throws the wrong exception type for remove(first | last) operations

On Tue, 2 Apr 2024 10:37:02 GMT, Per Minborg wrote: > This PR proposes to make empty immutable lists always throw UOE on > `removeFirst` and `removeLast`. LGTM - Marked as reviewed by rriggs (Reviewer). PR Review:

Re: RFR: JDK-8329089: Empty immutable list throws the wrong exception type for remove(first | last) operations

On Tue, 2 Apr 2024 10:37:02 GMT, Per Minborg wrote: > This PR proposes to make empty immutable lists always throw UOE on > `removeFirst` and `removeLast`. test/jdk/java/util/Collection/MOAT.java line 573: > 571: c::removeLast); > 572: } > 573: Would this test better if

Re: RFR: 8328700: Unused import and variable should be deleted in regex package

On Fri, 22 Mar 2024 17:58:25 GMT, Raffaello Giulietti wrote: > Make use of an unused local variable probably intended to replace later casts. Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18460#pullrequestreview-195551

Re: CFV: New Core Libraries Group Member: Per-Ake Minborg

Vote: Yes On 3/19/24 11:19 AM, Daniel Fuchs wrote: I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the Core Libraries Group [4].

Re: RFR: 8328524: [x86] StringRepeat.java failure on linux-x86: Could not reserve enough space for 2097152KB object heap

On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier wrote: > …rve enough space for 2097152KB object heap > > I would like to fix this as the two related issues mentioned in the JBS bug. > We see it currently in most GHA runs. lgtm - Marked as reviewed by rriggs (Reviewer). PR

Re: RFR: 8328261: public lookup fails with IllegalAccessException when used while module system is being initialized

On Mon, 18 Mar 2024 17:40:26 GMT, Mandy Chung wrote: > A simple fix. This is caused by a bug in `VerifyAccess::isClassAccessible` > that checks if a class is exported from `java.base` before the exports are > fully setup.It should check if the module system is fully initialized > before

Re: RFR: 8327964: Simplify BigInteger.implMultiplyToLen intrinsic

On Tue, 12 Mar 2024 10:44:54 GMT, Yudi Zheng wrote: > Moving array construction within BigInteger.implMultiplyToLen intrinsic > candidate to its caller simplifies the intrinsic implementation in JIT > compiler. src/java.base/share/classes/java/math/BigInteger.java line 1836: > 1834: > 1835:

Re: RFR: 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]

On Wed, 13 Mar 2024 20:10:25 GMT, Roger Riggs wrote: >> The intermittent failure of ObjectStreamClassCaching is due to an incorrect >> assumption about GC behavior and a race condition. >> >> Removed test based on incorrect assumptions about simultaneous cleari

Integrated: 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1

On Wed, 13 Mar 2024 18:01:21 GMT, Roger Riggs wrote: > The intermittent failure of ObjectStreamClassCaching is due to an incorrect > assumption about GC behavior and a race condition. > > Removed test based on incorrect assumptions about simultaneous clearing of > WeakRefe

Re: RFR: 8326941: Remove StringUTF16::isBigEndian

On Mon, 18 Mar 2024 14:09:09 GMT, Per Minborg wrote: > This PR proposes to remove the native method `StringUTF16::isBigEndian` and > its corresponding C implementation and instead rely on the > `jdk.internal.misc.Unsafe::isBigEndian` method. Nice Cleanup. - Marked as reviewed by

Re: RFR: 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v3]

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect > assumption about GC behavior and a race condition. > > Removed test based on incorrect assumptions about simultaneous clearing of > WeakReferences. > Added a run of the test using ZGC, (previous

Re: RFR: 8325621: Improve jspawnhelper version checks [v4]

On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote: >> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) >> >> Updates jspawnhelper to check that JDK version and jspawnhelper version are >> the same. Updates test to include check for version. Also tested manually by >>

Re: RFR: 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1 [v2]

> The intermittent failure of ObjectStreamClassCaching is due to an incorrect > assumption about GC behavior and a race condition. > > Removed test based on incorrect assumptions about simultaneous clearing of > WeakReferences. > Added a run of the test using ZGC, (previous

RFR: 8327180: Failed: java/io/ObjectStreamClass/ObjectStreamClassCaching.java#G1

The intermittent failure of ObjectStreamClassCaching is due to an incorrect assumption about GC behavior and a race condition. Removed test based on incorrect assumptions about simultaneous clearing of WeakReferences. Added a run of the test using ZGC, (previously omitted) -

Re: RFR: 8327998: Enable java/lang/ProcessBuilder/JspawnhelperProtocol.java on Mac

On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan wrote: > This change enables to run JspawnhelperProtocol.java on MacOS. > > In addition to GHA , the test has been run on macos and linux. > > > Test report is stored in >

Re: RFR: 8325621: Improve jspawnhelper version checks [v2]

On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote: >> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621) >> >> Updates jspawnhelper to check that JDK version and jspawnhelper version are >> the same. Updates test to include check for version. Also tested manually by >>

Re: RFR: 8327705: Remove mention of "applet" from java.text package description [v2]

On Mon, 11 Mar 2024 16:32:31 GMT, Naoto Sato wrote: >> Removing left over "applet" mention in the package-info doc. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Addressing review comments Marked as reviewed by rriggs

Re: RFR: 8327705: Remove mention of "applet" from java.text package description

On Fri, 8 Mar 2024 19:54:31 GMT, Naoto Sato wrote: > Removing left over "applet" mention in the package-info doc. bye bye - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18173#pullrequestreview-1925798262

Re: RFR: 8325567: jspawnhelper without args fails with segfault [v8]

On Fri, 8 Mar 2024 17:24:24 GMT, Elif Aslan wrote: >> This change is intended to address the segmentation fault issue that occurs >> when jspawnhelper is called without arguments,. >> There is a new test added to verify the behavior in such cases. >> >> `[ec2-user@ip-172-16-0-10 jdk]$ make

Re: RFR: 8327167: Clarify the handling of Leap year by Calendar

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato wrote: > A simple doc update to include a leap day example in the `Calendar` class. Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1925260836

Re: RFR: 8325567: jspawnhelper without args fails with segfault [v7]

On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote: >> This change is intended to address the segmentation fault issue that occurs >> when jspawnhelper is called without arguments,. >> There is a new test added to verify the behavior in such cases. >> >> `[ec2-user@ip-172-16-0-10 jdk]$ make

Re: RFR: 8327434: Test java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato wrote: > Fixing timeout failures in the test case. Time zone names that are missing > (chiefly for minor locales) are now calculated at runtime after the fix to > JDK-8174269. This extra calculation time was multiplied in the test case as > it

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v4]

On Tue, 5 Mar 2024 20:23:56 GMT, Jim Laskey wrote: >> Currently, add is returning intern(e) == null which will always be false. >> The correct test is intern(e) == e , that is, true when element is newly >> added. > > Jim Laskey has updated the pull request incrementally with one additional >

Re: RFR: 8325567: jspawnhelper without args fails with segfault

On Mon, 4 Mar 2024 23:54:38 GMT, Vladimir Petko wrote: >> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 111: >> >>> 109: if (p.exitValue() != 1) >>> 110: System.exit(ERROR + 2); >>> 111: System.exit(0); >> >> Its bad form to System.exit from not

Re: RFR: 8325567: jspawnhelper without args fails with segfault

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote: > This change is intended to address the segmentation fault issue that occurs > when jspawnhelper is called without arguments, and it includes an updated > test to verify the behavior in such cases. > > Existing tests passes since it does not

Re: RFR: 8325567: jspawnhelper without args fails with segfault

On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote: > This change is intended to address the segmentation fault issue that occurs > when jspawnhelper is called without arguments, and it includes an updated > test to verify the behavior in such cases. > > Existing tests passes since it does not

Re: RFR: JDK-8326908: DecimalFormat::toPattern throws OutOfMemoryError when pattern is empty string

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu wrote: > Please review this PR and corresponding CSR which prevents an > OutOfMemoryError by restricting the initial maximum fraction digits for an > empty pattern DecimalFormat. > > For an empty String pattern DecimalFormat, the maximum fraction

Re: RFR: 8327225: Revert DataInputStream.readUTF to static final

On Mon, 4 Mar 2024 13:55:15 GMT, Claes Redestad wrote: > [JDK-8325340](https://bugs.openjdk.org/browse/JDK-8325340) accidentally > removed `final` from the `static final DataInputStream.readUTF` method. This > has a minor compatibility impact (allows hiding the method in a subclass, > while

Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v11]

On Fri, 1 Mar 2024 21:29:17 GMT, Naoto Sato wrote: >> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 >> where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored >> the in-house cache with WeakHashMap, and removed the Key class as it is no >> longer

Re: RFR: 8326714: Make file-local functions static in src/java.base/unix/native/libjava/childproc.c

On Tue, 27 Feb 2024 03:11:37 GMT, Jiangli Zhou wrote: > Please help review this trivial change. This was branched from > https://github.com/openjdk/jdk/pull/18013, based on discussion with > @plummercj in https://github.com/openjdk/jdk/pull/18013 comments. Thanks Marked as reviewed by rriggs

Re: RFR: 8325340: Add ASCII fast-path to Data-/ObjectInputStream.readUTF [v7]

On Fri, 16 Feb 2024 15:31:07 GMT, Claes Redestad wrote: >> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via >> Data- and ObjectInputStream >> >> Testing: tier1-3 > > Claes Redestad has updated the pull request incrementally with two additional > commits since the last

Re: RFR: 8326653: Remove jdk.internal.reflect.UTF8 [v2]

On Mon, 26 Feb 2024 11:34:18 GMT, Claes Redestad wrote: >> jdk.internal.reflect.UTF8 is used for encoding String to encoded UTF-8 when >> generating some classes. >> >> Since JDK 9 we have a fast-path (which avoids creating encoders) for >> UTF-8-encoding strings which is bootstrapped very

Re: CFV: New Core Libraries Group Member: Viktor Klang

Vote: Yes On 2/19/24 6:40 PM, Stuart Marks wrote: I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4].

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

On Tue, 13 Feb 2024 21:23:29 GMT, Dan Lutker wrote: >> At the time `sleep` seemed ubiquitous and was native so it ran quickly. >> (Much quicker than running java). >> Running another program would be fine. For example ,selecting an executable >> based on the OS type and giving the expected

Re: CFV: New Core Libraries Group Member: Raffaello Giulietti

Vote: Yes On 2/13/24 3:25 PM, Brian Burkhalter wrote: I hereby nominate Raffaello Giulietti to Membership in the Core Libraries Group.

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

On Tue, 13 Feb 2024 18:24:10 GMT, Dan Lutker wrote: >> To be fair, this looks similar to what `isMusl()` does: searching for >> strings in outputs. But I do wonder if `--help` would include "sleep" for >> some innocuous description somewhere, and this code would accidentally >> match.

Re: RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary

On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker wrote: > Ran the test on AmazonLinux 2 which has multiple binaries from coreutils > package and no coreutils executable as well as AmazonLinux 2023 that uses > `--enable-single-binary` test/lib/jdk/test/lib/Platform.java line 145: > 143: } >

[jdk22] Withdrawn: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk22/pull/110

Re: [jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

On Tue, 13 Feb 2024 15:57:31 GMT, Roger Riggs wrote: > 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 The backport was intended to be for jdk22u - PR Comment: https://git.openjdk.org/jdk22/pull/110#issuecomment-1941927141

[jdk22] RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 - Commit messages: - Backport 13d9e8ff38536287b82c54bb63bd2d20f65615dc Changes: https://git.openjdk.org/jdk22/pull/110/files Webrev: https://webrevs.openjdk.org/?repo=jdk22=110=00 Issue:

Integrated: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

On Mon, 12 Feb 2024 21:29:02 GMT, Roger Riggs wrote: > Correct the result string coder of a string encoded using a CharsetDecoder > with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. This pull request has now been integrated. Changeset: 13d9e8

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

> Correct the result string coder of a string encoded using a CharsetDecoder > with multi-byte encoded input. > Added tests for UTF16 strings and a regression test. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision

Re: RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 [v2]

On Tue, 13 Feb 2024 07:21:01 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Test Files.readString with multiple charsets >> Cleanup regression test to match sty

RFR: 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906

Correct the result string coder of a string encoded using a CharsetDecoder with multi-byte encoded input. Added tests for UTF16 strings and a regression test. - Commit messages: - 8325590: Regression in round-tripping UTF-16 strings after JDK-8311906 Changes:

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v7]

On Thu, 8 Feb 2024 21:29:19 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) >> which adds MessageFormat pattern support for the following subformats: >> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is >> intended to

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]

On Wed, 7 Feb 2024 00:48:30 GMT, Naoto Sato wrote: >> One idea would be to delegate to a (package-private) method in the formatXXX >> class. >> That would localize to the respective class the details. >> (An abstract protected method might be preferred, but its not worth creating >> extra

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]

On Tue, 6 Feb 2024 22:31:32 GMT, Justin Lu wrote: >> src/java.base/share/classes/java/text/MessageFormat.java line 681: >> >>> 679: if (fmt instanceof NumberFormat) { >>> 680: // Add any instances returned from the NumberFormat >>> factory methods >>> 681: if

Re: RFR: JDK-8325255 jdk.internal.util.ReferencedKeySet::add using wrong test [v2]

On Tue, 6 Feb 2024 13:56:09 GMT, Jim Laskey wrote: >> Currently, add is returning intern(e) == null which will always be false. >> The correct test is intern(e) == e , that is, true when element is newly >> added. > > Jim Laskey has updated the pull request with a new target base due to a

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]

On Fri, 2 Feb 2024 22:24:49 GMT, Naoto Sato wrote: >> We discussed this separately, but will go over again here in case others are >> interested. Since DTF does not implement `equals()`, even if we implement >> `equals()` for the `ClassicFormat`, we would basically still need to >> implement

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter [v4]

On Mon, 5 Feb 2024 23:51:00 GMT, Justin Lu wrote: >> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) >> which adds MessageFormat pattern support for the following subformats: >> ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is >> intended to

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v10]

On Mon, 5 Feb 2024 12:34:02 GMT, Jim Laskey wrote: >> src/java.base/share/classes/jdk/internal/util/ReferencedKeySet.java line 151: >> >>> 149: @Override >>> 150: public boolean add(T e) { >>> 151: return intern(e) == null; >> >> This line is wrong, as `intern(…)` will never

Re: RFR: 8325169: Reduce String::indexOf overheads [v3]

On Sat, 3 Feb 2024 14:36:14 GMT, Claes Redestad wrote: >> This patch streamlines and specializes various `String::indexOf` methods. >> Mainly avoids the need for clamping and doing checks that are redundant in >> almost all cases, moving the checks to the API boundary where they are >>

Re: RFR: 8324665: Loose matching of space separators in the lenient date/time parsing mode

On Fri, 2 Feb 2024 21:08:33 GMT, Joe Wang wrote: > You are right, Joe. Apps using `java.time` formatters would still need to > make changes to their code base. However, the bar is significantly lower. > They would have to write some ugly workaround without this fix. I'd also expect that

Re: RFR: 8325169: Reduce String::indexOf overheads

On Fri, 2 Feb 2024 13:54:46 GMT, Claes Redestad wrote: > This patch streamlines and specializes various `String::indexOf` methods. > Mainly avoids the need for clamping and doing checks that are redundant in > almost all cases, moving the checks to the API boundary where they are > needed. >

Re: RFR: 8321468: Remove StringUTF16::equals

On Wed, 6 Dec 2023 14:20:14 GMT, Claes Redestad wrote: > https://bugs.openjdk.org/browse/JDK-8215017 removed the only use of > `StringUTF16::equals`. At the time I did some performance verification > focused on x86 showing that simplifying and only using `StringLatin1::equals` > was either

Re: RFR: 8325109: Sort method modifiers in canonical order

On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote: > This is a follow-up on > [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the > bin/blessed-modifier-order.sh on the entire code base, and manually checked > the result. I have reverted all but these trivial

Re: RFR: 8324960: Unsafe.allocateMemory documentation incorrect regarding zero return value

On Wed, 31 Jan 2024 01:17:07 GMT, Brian Burkhalter wrote: > Align the specification of `Unsafe.allocateMemory` with its implementation > and with the specification of `Unsafe.reallocateMemory`. lgtm - Marked as reviewed by rriggs (Reviewer). PR Review:

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v13]

On Fri, 26 Jan 2024 17:36:52 GMT, Jim Laskey wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide full

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to >> pattern string via `toPattern()` and then back via `new MessageFormat()` >> results in a format that is equivalent to the original. >> >> The quoting and escaping

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v12]

On Fri, 26 Jan 2024 15:06:50 GMT, Jim Laskey wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide full

Integrated: 8324657: Intermittent OOME on exception message create

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

Re: RFR: 8324657: Intermittent OOME on exception message create [v2]

all can improve exception handling. > > Writing a test of the exact failure condition has proved challenging due to > the unpredictable state of memory when OOME occurs. The replacement of "+" > with String.concat() is simple and direct. Roger Riggs has updated the pull requ

RFR: 8324657: Intermittent OOME on exception message create

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. Explicit use of String.concat() call can improve exception

Re: RFR: JDK-8321545: Override toString() for Format subclasses [v5]

On Fri, 12 Jan 2024 22:41:46 GMT, Justin Lu wrote: >> Please review this PR which implements toString() for the `Format` >> subclasses. Corresponding CSR: >> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088) >> >> The general specification follows a template that provides the locale

Re: RFR: 8323717: Introduce test keyword for tests that need external dependencies

On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote: > Some jtreg tests require resolvable external dependencies. This resolution is > delegated to JIB, which is not used in vanilla OpenJDK testing. It would be > convenient to add a keyword that marks tests that require these external >

Re: RFR: JDK-8263261 Extend String::translateEscapes to support unicode escapes [v7]

On Fri, 19 Jan 2024 18:23:40 GMT, Jim Laskey wrote: >> Currently String::translateEscapes does not support unicode escapes, >> reported as a IllegalArgumentException("Invalid escape sequence: ..."). >> String::translateEscapes should translate unicode escape sequences to >> provide full

Re: RFR: JDK-8321545: Override toString() for Format subclasses [v4]

On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu wrote: >> Please review this PR which implements toString() for the `Format` >> subclasses. Corresponding CSR: >> [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088) >> >> The general specification follows a template that provides the locale

Re: RFR: 8275338: Add JFR events for notable serialization situations [v14]

On Wed, 10 Jan 2024 18:56:45 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > Small space optimization. Thanks for the updates.

Re: [jdk22] RFR: 8320788: The system properties page is missing some properties

On Wed, 10 Jan 2024 20:56:14 GMT, Naoto Sato wrote: > Backporting the document only fix to jdk22 Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk22/pull/59#pullrequestreview-1814171861

Re: RFR: 8275338: Add JFR events for notable serialization situations [v4]

On Wed, 10 Jan 2024 17:41:41 GMT, Raffaello Giulietti wrote: >> The spec is silent about methods being 'native'; it would generally be >> impractical to implement native methods for these purposes, but a native >> method can implement the behavior. > > @RogerRiggs The checks are agnostic

Re: RFR: JDK-8322878: Including sealing information Class.toGenericString() [v7]

On Wed, 10 Jan 2024 18:16:05 GMT, Joe Darcy wrote: >> As recently discussed on core libs, sealed-ness information could be >> included in the Class.toGenericString() output, analagous to how "modifiers" >> that also correspond to JVM access flags are handled. >> >> This is the initial spec,

Re: RFR: 8275338: Add JFR events for notable serialization situations [v4]

On Tue, 19 Dec 2023 15:58:10 GMT, Raffaello Giulietti wrote: >> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java >> line 185: >> >>> 183: commitEvent(PRIV_METH_NON_STATIC, >>> 184: m + " must be non-static to be effective"); >>> 185:

Re: RFR: 8275338: Add JFR events for notable serialization situations [v13]

On Wed, 10 Jan 2024 15:43:46 GMT, Raffaello Giulietti wrote: >> Adds serialization misdeclaration events to JFR. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > Changes according to reviewers feedback.

  1   2   3   4   5   6   7   8   9   10   >