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.
>
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
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
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:
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
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
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
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
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
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
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
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
>
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
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
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.
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
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
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,
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:
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.
On Tue, 9 Jan 2024 10:41:31 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 53:
>>
>>> 51: private static final Class[] READ_OBJECT_NO_DATA_PARAM_TYPES =
>>> {};
>>> 52: private static final Class[]
On Wed, 10 Jan 2024 14:58:37 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/BigInteger.java line 3998:
>>
>>> 3996: int i = ArraysSupport.mismatch(m1, m2, len1);
>>> 3997: if (i != -1)
>>> 3998: return Integer.compareUnsigned(m1[i], m2[i])
On Wed, 10 Jan 2024 11:27:53 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals, hashCode, and compareTo for BigInteger. If you have any performance
>> concerns, please raise them.
>>
>> This PR is cherry-picked from a bigger,
On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato wrote:
>> Adding an explanation of the locale-related system properties in the
>> `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since
On Tue, 9 Jan 2024 20:01:28 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 819:
>
>> 817: *
>> 818: *
On Tue, 9 Jan 2024 19:37:54 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,
On Tue, 2 Jan 2024 14:37:27 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals, hashCode, and compareTo for BigInteger. If you have any performance
>> concerns, please raise them.
>>
>> This PR is cherry-picked from a bigger,
On Mon, 8 Jan 2024 13:48:06 GMT, Raffaello Giulietti
wrote:
>> Adds serialization misdeclaration events to JFR.
>
> Raffaello Giulietti 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
On Wed, 3 Jan 2024 06:43:22 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,
you think?
On 2 Jan 2024, at 16:56, Roger Riggs wrote:
Hi Pavel,
It better to look to javax.lang.model.element.Modifier for the language view of
the class.
java.lang.reflect.Modifier covers the modifier flags as represented in the
class file and defined in the JVMS.
* The values
private abstract static final transient volatile
synchronized native strictfp interface
It does not seem like `sealed` and `non-sealed` are even modelled by
java.lang.reflect.Modifier, although `sealed` is modelled by
`java.lang.Class#isSealed`. It cannot be overlook, can it?
On 2 Jan 2024, at 14
Hi Pavel,
yes, a PR would be next.
Happy New Year, Roger
On 1/2/24 7:08 AM, Pavel Rappo wrote:
I assume the order for `sealed` and `non-sealed` has effectively been decided
by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
8.1.1. Class Modifiers
...
On Sat, 23 Dec 2023 15:22:58 GMT, Eamonn McManus wrote:
>> Multiplying with `*` never produces `ArithmeticException`, so the catch in
>> the existing code is never triggered. `Math.multiplyExact` does produce
>> `ArithmeticException` if the multiplication overflows. So we can use that,
>> and
On Thu, 21 Dec 2023 09:53:10 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:
>
> Corrected @Label of event and of field.
On Wed, 20 Dec 2023 22:15:04 GMT, Jim Laskey wrote:
>> The new repeat methods were not clearing the toStringCache.
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clear sooner
LGTM
-
Marked as reviewed by
On Wed, 20 Dec 2023 20:25:07 GMT, Jim Laskey wrote:
> The new repeat methods were not clearing the toStringCache.
src/java.base/share/classes/java/lang/StringBuffer.java line 719:
> 717: public synchronized StringBuffer repeat(int codePoint, int count) {
> 718:
On Wed, 20 Dec 2023 14:28:39 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewer's comments.
>
> It would also be useful/interesting
On Wed, 20 Dec 2023 15:01:02 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/SerializationMisdeclarationChecker.java
>> line 113:
>>
>>> 111: if (longFromStatic(f) == null) {
>>> 112: commitEvent(SUID_CONVERTIBLE_TO_LONG,
>>> 113:
On Tue, 19 Dec 2023 16:45:04 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 reviewer's comments.
It would
On Tue, 19 Dec 2023 16:45:04 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 reviewer's comments.
On Wed, 20 Dec 2023 08:29:19 GMT, Daniel Fuchs wrote:
>> You could define them with an Enum but use the ordinal as the value for JFR.
>
> Same remark here about finality as
> https://github.com/openjdk/jdk/pull/17129#discussion_r1432400888. public
> statics should be final.
I'd also remove
On Tue, 19 Dec 2023 12:21:05 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:
>
> Better name for a label, corrected name of removed
On Tue, 19 Dec 2023 17:41:57 GMT, Raffaello Giulietti
wrote:
>> Users (not OpenJDK developers) don't know what the error code means. I think
>> it's better to not have them. This is how other events work. If you want to
>> guard against changes, I would export the package to the test.
>
>
jdk) repository.
>
> The commit being backported was authored by Aleksei Voitylov on 14 Dec 2023
> and was reviewed by Roger Riggs.
>
> Thanks!
Identical to mainline commit. Looks good
-
Marked as reviewed by rriggs (Reviewer).
PR Review: https://git.openjdk.org/jdk22/pull/18#pullrequestreview-1789030091
On Wed, 13 Dec 2023 21:38:43 GMT, Roger Riggs wrote:
> The test java/lang/String/CompactString/MaxSizeUTF16String.java fails when
> run with -Xcomp.
>
> Both the java implementation and the intrinsic for StringUTF16.toBytes()
> allocate memory for a copy of the str
On Wed, 13 Dec 2023 19:00:52 GMT, Naoto Sato wrote:
>> This is a doc change to clarify what the `Default Locale` is, and how it is
>> established during the system startup using the system properties. Those
>> locale-related system properties have existed since the early days of Java,
>> but
On Thu, 14 Dec 2023 12:03:11 GMT, Aleksei Voitylov
wrote:
> Thank you, Roger. Yes, I'll work on the 22 backport.
See https://wiki.openjdk.org/display/SKARA/Backports
Once the mainline is integrated, find the commit and add a "/backport jdk21"
comment.
Skara should do the rest (but read the
The test java/lang/String/CompactString/MaxSizeUTF16String.java fails when run
with -Xcomp.
Both the java implementation and the intrinsic for StringUTF16.toBytes()
allocate memory for a copy of the string.
The java implementation of `toBytes()` throws an exception with a message in
terms of
On Wed, 13 Dec 2023 18:01:55 GMT, Naoto Sato wrote:
>> This is a doc change to clarify what the `Default Locale` is, and how it is
>> established during the system startup using the system properties. Those
>> locale-related system properties have existed since the early days of Java,
>> but
On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov
wrote:
>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered
>> when calling extractCodepoints from StringUTF16.toBytes(). Because of that
>> the last elements of the source codepoints array are stripped from the
>>
On Wed, 13 Dec 2023 11:39:29 GMT, Aleksei Voitylov
wrote:
> If you think it's worth it, I can go through some tests and add some more
> -XX:-CompactStrings mode to java.lang.String tests here and there, lightly.
> It's not the first time we hit this issue.
Verifying the coverage of the tests
On Wed, 13 Dec 2023 11:39:19 GMT, Aleksei Voitylov
wrote:
>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered
>> when calling extractCodepoints from StringUTF16.toBytes(). Because of that
>> the last elements of the source codepoints array are stripped from the
>>
On Tue, 12 Dec 2023 10:57:20 GMT, Aleksei Voitylov
wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review comments
>
> Thanks Roger. I agree with your point and pulled your suggested test in the
> PR.
On Wed, 6 Dec 2023 23:31:26 GMT, Roger Riggs wrote:
> In the compact string implementation of non-latin1 (UTF16) strings the length
> is constrained by VM implementation limit on the size a byte array that can
> be allocated. To produce a useful exception the implementati
On Tue, 12 Dec 2023 10:47:48 GMT, Aleksei Voitylov
wrote:
>> Since JDK-8311906, if CompactStrings is not enabled, index is not considered
>> when calling extractCodepoints from StringUTF16.toBytes(). Because of that
>> the last elements of the source codepoints array are stripped from the
>>
On Mon, 11 Dec 2023 13:48:18 GMT, Aleksei Voitylov
wrote:
> Since JDK-8311906, if CompactStrings is not enabled, index is not considered
> when calling extractCodepoints from StringUTF16.toBytes(). Because of that
> the last elements of the source codepoints array are stripped from the
>
e array size. The exception message is
> correct
>
> "UTF16 String size is " + len + ", should be less than or equal to " +
> MAX_LENGTH
>
> The code should match the message, otherwise the exception thrown is:
>
> java.lang.OutOfMemoryError: Requested array
On Fri, 8 Dec 2023 19:32:02 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/lang/StringUTF16.java line 59:
>>
>>> 57: if (len >= MAX_LENGTH) {
>>> 58: throw new OutOfMemoryError("UTF16 String size is " + len +
>>> 59:
e array size. The exception message is
> correct
>
> "UTF16 String size is " + len + ", should be less than or equal to " +
> MAX_LENGTH
>
> The code should match the message, otherwise the exception thrown is:
>
> java.lang.OutOfMemoryError: Requested array
In the compact string implementation of non-latin1 (UTF16) strings the length
is constrained by VM implementation limit on the size a byte array that can be
allocated. To produce a useful exception the implementation checks the string
size against the maximum byte array size. The exception
On Wed, 6 Dec 2023 20:55:48 GMT, Naoto Sato wrote:
>> Currently, Locale-related system properties, such as `user.language` or
>> `user.country`, are initialized when the `Locale` class is loaded. Making
>> them static properties is safer than relying on the `Locale` class loading
>> timing,
On Wed, 6 Dec 2023 17:56:58 GMT, Jim Laskey wrote:
>> A regression is found in Java9+ creating String instance from UTF8 bytes, a
>> side effect of string compactation https://openjdk.org/jeps/254 that changed
>> the decoding logic. Specifically, when constructing a string from bytes:
>>
>>
On Tue, 5 Dec 2023 23:04:55 GMT, Naoto Sato wrote:
> Currently, Locale-related system properties, such as `user.language` or
> `user.country`, are initialized when the `Locale` class is loaded. Making
> them static properties is safer than relying on the class initialization
> timing, which
On Wed, 6 Dec 2023 11:47:13 GMT, Jim Laskey wrote:
>> A regression is found in Java9+ creating String instance from UTF8 bytes, a
>> side effect of string compactation https://openjdk.org/jeps/254 that changed
>> the decoding logic. Specifically, when constructing a string from bytes:
>>
>>
On Tue, 5 Dec 2023 20:13:06 GMT, Jim Laskey wrote:
>> A regression is found in Java9+ creating String instance from UTF8 bytes, a
>> side effect of string compactation https://openjdk.org/jeps/254 that changed
>> the decoding logic. Specifically, when constructing a string from bytes:
>>
>>
On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey wrote:
> A regression is found in Java9+ creating String instance from UTF8 bytes, a
> side effect of string compactation https://openjdk.org/jeps/254 that changed
> the decoding logic. Specifically, when constructing a string from bytes:
>
> ```
On Tue, 5 Dec 2023 14:57:09 GMT, Jim Laskey wrote:
> A regression is found in Java9+ creating String instance from UTF8 bytes, a
> side effect of string compactation https://openjdk.org/jeps/254 that changed
> the decoding logic. Specifically, when constructing a string from bytes:
>
> ```
On Sat, 2 Dec 2023 15:42:18 GMT, fabioromano1 wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last
On Mon, 30 Oct 2023 18:34:44 GMT, Roger Riggs wrote:
> Strings, after construction, are immutable but may be constructed from
> mutable arrays of bytes, characters, or integers.
> The string constructors should guard against the effects of mutating the
> arrays during constructio
On Thu, 30 Nov 2023 08:00:12 GMT, Damon Fenacci wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use byte off branches in char_array_compress
>> Verified by manual tests with "
On Thu, 30 Nov 2023 21:51:19 GMT, Naoto Sato wrote:
>> Removing the unnecessary array assignments.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use Arrays.fill()
LGTM
-
Marked as reviewed by rriggs
On Mon, 27 Nov 2023 22:58:17 GMT, fabioromano1 wrote:
>> A faster and simpler way to generate random BigIntegers, avoiding eventually
>> trimming of leading zeros in magnitude array.
>
> fabioromano1 has updated the pull request incrementally with one additional
> commit since the last
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
Hi Anthony,
Go ahead a file a single bug (for the two cases).
That code may have been written before Arrays.fill(...).
Regards, Roger
On 11/29/23 7:54 AM, Anthony Goubard wrote:
Hello,
Last Friday, I decided to look if there were some classes that did
unneeded array assignments (e.g. to 0
On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote:
> Typo fix to to the new text added in JDK-8295391.
LGTM
-
Marked as reviewed by rriggs (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1754293335
On Mon, 27 Nov 2023 16:58:29 GMT, Alan Bateman wrote:
> ThreadGroup.stop was deprecated since JDK 1.2, deprecated for removal in Java
> 18, and re-specified/degraded to throw UnsupportedOperationException
> unconditionally in Java 20. Early in Java 23 seems a fine time to finally
> remove
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Mon, 27 Nov 2023 13:43:52 GMT, Damon Fenacci wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Apply StringUTF16.coderFromArrayLen
>
> src/hotspot/cpu/x86/macroAssembler_x86.cpp line
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Mon, 13 Nov 2023 22:31:16 GMT, Brent Christian wrote:
> Classes in the `java.lang.ref` package would benefit from an update to bring
> the spec in line with how the VM already behaves. The changes would focus on
> _happens-before_ edges at some key points during reference processing.
>
> A
On Wed, 15 Nov 2023 22:31:35 GMT, Stuart Marks wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
>>
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Sun, 19 Nov 2023 02:19:52 GMT, Shaojin Wen wrote:
>> `JapaneseChronology` is not extending `IsoChronology`, and that is the gist
>> of the change I suggested.
>
> I added the testcase of IsoChronology and it also passed.
The distinction is pretty subtle, I was referring to the
On Fri, 17 Nov 2023 23:35:37 GMT, Naoto Sato wrote:
>> Haven't tried, but I think `t.getChronology() instanceof IsoChronology`
>> should work
>
> Now I tried and it didn't compile It should have been
> `t.query(TemporalQueries.chronology()) instanceof IsoChronology`
JapaneseChronology is an
On Fri, 10 Nov 2023 03:31:26 GMT, Shaojin Wen wrote:
>> j.u.Formatter now prints "%tF" (iso standard date) and the result is
>> incorrect when processing year < 0 or year >
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Wed, 15 Nov 2023 15:23:48 GMT, Raffaello Giulietti
wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update PPC implementation of string_compress to return the index of the
>> non-l
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato wrote:
>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> abbreviated/full clarification
Marked as reviewed by
On Tue, 14 Nov 2023 17:14:06 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/text/DateFormat.java line 120:
>>
>>> 118: * result; from {@link #SHORT} to {@link #MEDIUM} to {@link #LONG} to
>>> {@link #FULL}. The exact result depends
>>> 119: * on the locale, but generally:
>>>
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Tue, 14 Nov 2023 16:05:51 GMT, Roger Riggs wrote:
>> Strings, after construction, are immutable but may be constructed from
>> mutable arrays of bytes, characters, or integers.
>> The string constructors should guard against the effects of mutating the
>> ar
nes whether the latin1 or the non-latin1 representation is
> returned.
>
> - The methods that scan for non-latin1 characters and their intrinsic
> implementations are updated to return the index of the non-latin1 character.
>
> - String construction from StringBuilder and CharSequ
On Thu, 9 Nov 2023 04:16:25 GMT, Roger Riggs wrote:
>> Strings, after construction, are immutable but may be constructed from
>> mutable arrays of bytes, characters, or integers.
>> The string constructors should guard against the effects of mutating the
>> ar
On Mon, 13 Nov 2023 18:41:08 GMT, Naoto Sato wrote:
>> Fixing the `Format::parseObject(String, ParsePosition)` implementation in
>> `DateTimeFormatter` class, to not throw `DateTimeException` but to return
>> null.
>
> Naoto Sato has updated the pull request incrementally with one additional
On Wed, 8 Nov 2023 21:58:47 GMT, Eamonn McManus wrote:
> This change simply replaces "period" with "duration", or in one case replaces
> "period unit" with just "unit".
Looks good.
I reviewed the CSR, it can be "Finalized" to get its review started.
-
Marked as reviewed by
101 - 200 of 1137 matches
Mail list logo
