On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann wrote:
> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459).
> Applies cleanly.
>
> Thanks,
> Tobias
This pull request has now been integrated.
Changeset: 9998c07b
Author:Tobias Hartmann
URL:
On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann wrote:
> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459).
> Applies cleanly.
>
> Thanks,
> Tobias
Thanks, Vladimir!
-
PR Comment: https://git.openjdk.org/jdk21/pull/68#issuecomment-1610754095
On Mon, 26 Jun 2023 14:58:56 GMT, Tingjun Yuan wrote:
> This PR changes the implementation of `Long.toUnsignedString(long, int)` for
> "default" radices, which avoids creating a `BigInteger` and makes use of
> `Long.divideUnsigned` and `Long.remainderUnsigned`.
>
> I've run the test on
This PR changes the implementation of `Long.toUnsignedString(long, int)` for
"default" radices, which avoids creating a `BigInteger` and makes use of
`Long.divideUnsigned` and `Long.remainderUnsigned`.
I've run the test on `test/jdk/java/lang/Long/Unsigned.java` and it works
correctly. I
On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote:
>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>>
>> Reasons:
>>
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset,
>> creating a new shortcut can make writing shorter;
>> * Since all possible values
On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote:
>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>>
>> Reasons:
>>
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset,
>> creating a new shortcut can make writing shorter;
>> * Since all possible values
> This patch implements lazy initialization for VarHandle working on static
> fields. It has a good initial call performance.
>
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
> implementation methods. If called via MethodHandle, a barrier is added in the
>
On Tue, 27 Jun 2023 20:48:57 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f07e396b](https://github.com/openjdk/jdk/commit/f07e396bda4567fd35677704b9aa974426266363)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Wed, 28 Jun 2023 00:18:25 GMT, Chen Liang wrote:
>> The API specification for descriptorString not being a strict inverse of
>> Class::forName and MethodType::fromDescriptorString are not entirely correct.
>>
>> 1. Class::descriptorString was never an inverse of Class::forName, which
>>
On Wed, 28 Jun 2023 00:18:25 GMT, Chen Liang wrote:
>> The API specification for descriptorString not being a strict inverse of
>> Class::forName and MethodType::fromDescriptorString are not entirely correct.
>>
>> 1. Class::descriptorString was never an inverse of Class::forName, which
>>
On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If
> The API specification for descriptorString not being a strict inverse of
> Class::forName and MethodType::fromDescriptorString are not entirely correct.
>
> 1. Class::descriptorString was never an inverse of Class::forName, which
> takes a binary name instead. The note about different class
On Wed, 28 Jun 2023 00:13:48 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If
On Tue, 27 Jun 2023 23:33:57 GMT, Chen Liang wrote:
>> test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 85:
>>
>>> 83:
>>> 84: @Test
>>> 85: public void testInitializationOnVarHandleUse() {
>>
>> I think we will need to expand this to also test operating on a MH to
> This patch implements lazy initialization for VarHandle working on static
> fields. It has a good initial call performance.
>
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
> implementation methods. If called via MethodHandle, a barrier is added in the
>
On Tue, 27 Jun 2023 21:14:23 GMT, Paul Sandoz wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rollback VHG changes
>
> test/jdk/java/lang/invoke/VarHandles/LazyInitializingTest.java line 85:
>
>> 83:
>> 84:
> This patch implements lazy initialization for VarHandle working on static
> fields. It has a good initial call performance.
>
> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
> implementation methods. If called via MethodHandle, a barrier is added in the
>
Please review this PR which refactors the majority of Currency tests to use
JUnit. (The leftover will be done in a separate PR).
The largest change is in `CurrencyTest.java`. To maintain the grouping of
similar tests, JUnit nested classes were used.
I also believe that `Bug4512215.java` should
> The socket read/write JFR events currently use instrumentation of java.base
> code using templates in the jdk.jfr modules. This results in some java.base
> code residing in the jdk.jfr module which is undesirable.
>
> JDK19 added static support for event classes. The old instrumentor classes
On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If
> The socket read/write JFR events currently use instrumentation of java.base
> code using templates in the jdk.jfr modules. This results in some java.base
> code residing in the jdk.jfr module which is undesirable.
>
> JDK19 added static support for event classes. The old instrumentor classes
On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote:
>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>>
>> Reasons:
>>
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset,
>> creating a new shortcut can make writing shorter;
>> * Since all possible values
On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote:
> Fix a test bug when run on aarch64, it was supposed to confirm it was not
> running on Arm.
This pull request has now been integrated.
Changeset: 7f094353
Author:Roger Riggs
URL:
Hi all,
This pull request contains a backport of commit
[f07e396b](https://github.com/openjdk/jdk/commit/f07e396bda4567fd35677704b9aa974426266363)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Jorn Vernee on 27 Jun 2023 and was
On Tue, 27 Jun 2023 13:57:31 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If
On Fri, 9 Jun 2023 18:59:41 GMT, Paul Sandoz wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove meaningless target calls and clear outdated cache as needed
>
> Something was bothering me about the current
On Mon, 26 Jun 2023 19:33:50 GMT, Jorn Vernee wrote:
> Remove 2 malformed problem list entries. These entries are considered
> malformed according to [1] since they are missing a bug number.
>
> The `java/foreign/callarranger/TestAarch64CallArranger.java` test was
> removed, and the
> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that can
> be used in many places to performance tuning.
>
> Currently they are implemented by `VarHandle`, so using them may have some
> impact on startup time.
>
> This PR reimplements them using `Unsafe`, which reduces
On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote:
> Fix a test bug when run on aarch64, it was supposed to confirm it was not
> running on Arm.
Marked as reviewed by bpb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501763673
On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote:
> Fix a test bug when run on aarch64, it was supposed to confirm it was not
> running on Arm.
Looks good.
-
Marked as reviewed by mchung (Reviewer).
PR Review:
On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote:
> Fix a test bug when run on aarch64, it was supposed to confirm it was not
> running on Arm.
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501766576
On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote:
> Fix a test bug when run on aarch64, it was supposed to confirm it was not
> running on Arm.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14685#pullrequestreview-1501758826
On Wed, 21 Jun 2023 16:29:40 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and
Fix a test bug when run on aarch64, it was supposed to confirm it was not
running on Arm.
-
Commit messages:
- Add bugid
- 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with
"Method isARM()..."
Changes: https://git.openjdk.org/jdk/pull/14685/files
On Tue, 27 Jun 2023 19:42:37 GMT, Joe Darcy wrote:
> Doc-only typo fix.
Marked as reviewed by mchung (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/73#pullrequestreview-1501744901
Doc-only typo fix.
-
Commit messages:
- Backport 4bce38c6d7792596879a6e1081140b698b899471
Changes: https://git.openjdk.org/jdk21/pull/73/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21=73=00
Issue: https://bugs.openjdk.org/browse/JDK-8310830
Stats: 1 line in 1 file
On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy wrote:
> Typo fix. I didn't see any other instances of similar typos in the class.
This pull request has now been integrated.
Changeset: 4bce38c6
Author:Joe Darcy
URL:
On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy wrote:
> Typo fix. I didn't see any other instances of similar typos in the class.
Marked as reviewed by mchung (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501705496
On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy wrote:
> Typo fix. I didn't see any other instances of similar typos in the class.
Marked as reviewed by bpb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501692413
On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy wrote:
> Typo fix. I didn't see any other instances of similar typos in the class.
Marked as reviewed by rriggs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501695302
On Tue, 27 Jun 2023 13:45:27 GMT, Matthias Baesken wrote:
>> Currently, a number of tests fail on macOS because they miss the core file
>> (e.g. serviceability/sa/TestJmapCore.java).
>> The reason is that configure detects on some setups that codesign does not
>> work ("checking if debug mode
On Tue, 27 Jun 2023 18:56:53 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
Marked as reviewed by darcy (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/72#pullrequestreview-1501665796
On Tue, 27 Jun 2023 18:56:53 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
This pull request has now been integrated.
Changeset: 033060b2
Author:Jim Laskey
URL:
https://git.openjdk.org/jdk21/commit/033060b22bfb740d25f465f0495bd9b4bea25764
Stats:
Typo fix. I didn't see any other instances of similar typos in the class.
-
Commit messages:
- JDK-8310830: typo in the parameter name in @throws of ClassDesc::ofDescriptor
Changes: https://git.openjdk.org/jdk/pull/14683/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14683=00
The nested class is incorrectly marked as protected.
-
Commit messages:
- Backport 315242b7417a4774765f139b841b385dc7c94c50
Changes: https://git.openjdk.org/jdk21/pull/72/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21=72=00
Issue:
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote:
> In cases where the implRead/implWrite call throws an exception, shouldn't the
> event contain that exception, or at least exception message? If it doesn't
> should it be emitted at all, or should another event be emitted instead?
Added
On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
This pull request has now been integrated.
Changeset: 315242b7
Author:Jim Laskey
URL:
https://git.openjdk.org/jdk/commit/315242b7417a4774765f139b841b385dc7c94c50
Stats: 1
On Thu, 22 Jun 2023 10:21:46 GMT, Alan Bateman wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Tue, 27 Jun 2023 15:20:33 GMT, Glavo wrote:
>> When the default Locale is `tr`, the jmod and jimage commands have the
>> following problems:
>>
>> * The jmod command does not correctly recognize the `list` mode typed in
>> lowercase;
>> * The jimage command cannot obtain the help
On Mon, 26 Jun 2023 22:36:43 GMT, Chen Liang wrote:
>> `MethodType::descriptorString` refers to method descriptor and
>> `Class::descriptorString` refers to class descriptor. I don't think it
>> helps to say "produce identical class descriptors in method descriptors".
>
> I think we can put
On Tue, 27 Jun 2023 15:20:33 GMT, Glavo wrote:
>> When the default Locale is `tr`, the jmod and jimage commands have the
>> following problems:
>>
>> * The jmod command does not correctly recognize the `list` mode typed in
>> lowercase;
>> * The jimage command cannot obtain the help
On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs wrote:
> It takes a local inconvenience try/catch and spreads the impact over multiple
> files and packages as well as bulking up JLA.
I don't quite understand what you mean.
The main goal of this PR is to get rid of those annoying try-catch, but
On Tue, 27 Jun 2023 17:58:05 GMT, Roger Riggs wrote:
> I don't think this is a productive change. It takes a local inconvenience
> try/catch and spreads the impact over multiple files and packages as well as
> bulking up JLA.
By this rationale, newStringUTF8NoRepl should be removed as well.
On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote:
>> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`.
>>
>> Reasons:
>>
>> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset,
>> creating a new shortcut can make writing shorter;
>> * Since all possible values
On Wed, 21 Jun 2023 16:29:40 GMT, Roger Riggs wrote:
>> In java.time packages, clarify timeline order javadoc to mention "before"
>> and "after" in the value of the `compareTo` method return values.
>> Add javadoc @see tags to isBefore and isAfter methods
>>
>> Replace use of "negative" and
On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs wrote:
> The internal enum jdk.internal.util.Architecture does not provide information
> about the big or little endianness or the address size (64 or 32 bits). The
> endian-ness and address size are intrinsic to the architecture.
>
> The values
On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato wrote:
>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> Naoto Sato 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
On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato wrote:
>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> Naoto Sato 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
On Tue, 27 Jun 2023 17:07:50 GMT, Naoto Sato wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit
On Tue, 27 Jun 2023 17:30:35 GMT, 温绍锦 wrote:
>> By optimizing the implementation of java.lang.Long#fastUUID, the performance
>> of the java.util.UUID#toString method can be significantly improved.
>>
>> The following are the test results of JMH:
>>
>> Benchmark Mode Cnt
> By optimizing the implementation of java.lang.Long#fastUUID, the performance
> of the java.util.UUID#toString method can be significantly improved.
>
> The following are the test results of JMH:
>
> Benchmark Mode Cnt Score Error Units
>
> Docs only update to add a missing `@throws StructureViolationException` and
> make it clearer when the exception is thrown. In the future we might re-visit
> this so that the description is in one place rather than in each method.
Alan Bateman has updated the pull request incrementally with
> By optimizing the implementation of java.lang.Long#fastUUID, the performance
> of the java.util.UUID#toString method can be significantly improved.
>
> The following are the test results of JMH:
>
> Benchmark Mode Cnt Score Error Units
>
On Tue, 27 Jun 2023 16:35:20 GMT, Alan Bateman wrote:
> > Wenshao hopes to use this array for other optimizations in `java.lang` in
> > the future.
> > But as for this PR, I suggest wenshao not to do so much. I suggest moving
> > `DIGITS` back to `HexDigits` first to make the modifications in
On Mon, 26 Jun 2023 13:00:31 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this trivial change which adds the `@since` javadoc tag to the
> various ` java.sql `and `java.sql.rowset` packages.
>
> Best
> Lance
This pull request has now been integrated.
Changeset: fb283dff
Author:
On Tue, 27 Jun 2023 17:19:18 GMT, Daniel Fuchs wrote:
> I like the new text, it reads well. There's a typo that has been copy pasted
> several times however.
Thanks, I noticed this when looking at the generated javadoc but didn't commit
the change to fix. I'll fix it now.
-
PR
On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501494580
On Tue, 27 Jun 2023 15:34:58 GMT, Alan Bateman wrote:
> Docs only update to add a missing `@throws StructureViolationException` and
> make it clearer when the exception is thrown. In the future we might re-visit
> this so that the description is in one place rather than in each method.
I like
Hi all,
This pull request contains a backport of commit
[ec45bd64](https://github.com/openjdk/jdk/commit/ec45bd64d504d579aef54c924fb8ca75a944036f)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was
Hi core-libs-dev,
Over the past 6+ months I've been thinking about, and tinkering with, how we'd
be able to expose a user-facing API for extensible intermediate
java.util.stream.Stream operations—a feature envisioned all the way back when
Streams were created.
I'm now at a point where I have
On Tue, 27 Jun 2023 16:33:11 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>>
On Tue, 20 Jun 2023 20:54:43 GMT, Jens Lidestrom wrote:
> > A positive number is any number that is greater than 0. **Unlike positive
> > integers**, which include 0
>
> math.net seems pretty alone in this. I find the notion bizarre. There seems
> to be an overwhelming majority of sources
> Fixing the `/ by zero` exception with tick durations less than a millisecond.
Naoto Sato 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 contains four
On Tue, 27 Jun 2023 11:25:32 GMT, 温绍锦 wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
>> I'm looking through
>>
On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501400084
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1]
On Tue, 27 Jun 2023 16:11:43 GMT, Jim Laskey wrote:
> The nested class is incorrectly marked as protected.
Marked as reviewed by darcy (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14681#pullrequestreview-1501391798
On Tue, 27 Jun 2023 11:25:32 GMT, 温绍锦 wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> use ISO_8859_1.INSTANCE directly instead of StandardCharsets.ISO_8859_1
>
>> I'm looking through
>>
On Tue, 27 Jun 2023 07:46:24 GMT, Tobias Hartmann wrote:
> Backport of [JDK-8310459](https://bugs.openjdk.java.net/browse/JDK-8310459).
> Applies cleanly.
>
> Thanks,
> Tobias
Good.
-
Marked as reviewed by kvn (Reviewer).
PR Review:
The nested class is incorrectly marked as protected.
-
Commit messages:
- Remove protected from FormatItemModifier
Changes: https://git.openjdk.org/jdk/pull/14681/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=14681=00
Issue: https://bugs.openjdk.org/browse/JDK-8310975
On Tue, 27 Jun 2023 13:54:43 GMT, Roger Riggs wrote:
>> 温绍锦 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> fix UUID.java import, rename jdk.util.HexDigits to jdk.util.Hex256 and
>> make private constructor.
>
>
On Tue, 27 Jun 2023 14:32:14 GMT, Glavo wrote:
>> On second thought, we should be able to create a getter like
>>
>> @ForceInline
>> static short hex256(int byteValue) {
>> return HEX256[byteValue];
>> }
>>
>> and switch usages to that getter instead. This is a better approach than
>>
On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato wrote:
> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There
> are other locations than `ISO_LOCAL_DATE` that have the same description.
> Those are corrected too.
This pull request has now been integrated.
Changeset:
On Tue, 27 Jun 2023 07:23:21 GMT, Alan Bateman wrote:
>> Fixing the `/ by zero` exception with tick durations less than a millisecond.
>
> test/jdk/java/time/test/java/time/TestClock_Tick.java line 77:
>
>> 75: * Test tick clock.
>> 76: *
>> 77: * @bug 8310232
>
> Did you mean the put the
On Sun, 25 Jun 2023 09:18:34 GMT, Chen Liang wrote:
> This patch touches java.lang.reflect and java.lang.invoke packages. It
> replaces instanceof + cast with pattern matching and updates
> Array.newInstance().getClass() patterns with arrayType() for obtaining array
> types of a class.
This
> By optimizing the implementation of java.lang.Long#fastUUID, the performance
> of the java.util.UUID#toString method can be significantly improved.
>
> The following are the test results of JMH:
>
> Benchmark Mode Cnt Score Error Units
>
On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo wrote:
> Please review this cleanup PR to normalize names of identifiers which are
> Java variables/fields or tokens in text files. Those names either contain a
> pronoun that is very rarely used in code, or seem like they contain such a
>
Docs only update to add a missing `@throws StructureViolationException` and
make it clearer when the exception is thrown. In the future we might re-visit
this so that the description is in one place rather than in each method.
-
Commit messages:
- Initial commit
Changes:
On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote:
> Clarify the behavior of `java.lang.Readable` when the specified
> `java.nio.CharBuffer` parameter is empty but read-only, and when it is full.
This pull request has now been integrated.
Changeset: 58bb6555
Author:Brian Burkhalter
On Tue, 27 Jun 2023 07:45:51 GMT, Glavo wrote:
>> When the default Locale is `tr`, the jmod and jimage commands have the
>> following problems:
>>
>> * The jmod command does not correctly recognize the `list` mode typed in
>> lowercase;
>> * The jimage command cannot obtain the help
> When the default Locale is `tr`, the jmod and jimage commands have the
> following problems:
>
> * The jmod command does not correctly recognize the `list` mode typed in
> lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.
Glavo has updated the pull
> New functionality in the -XshowSettings menu to display relevant information
> about JDK security configuration
Sean Coffey 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.
> By optimizing the implementation of java.lang.Long#fastUUID, the performance
> of the java.util.UUID#toString method can be significantly improved.
>
> The following are the test results of JMH:
>
> Benchmark Mode Cnt Score Error Units
>
> The API specification for descriptorString not being a strict inverse of
> Class::forName and MethodType::fromDescriptorString are not entirely correct.
>
> 1. Class::descriptorString was never an inverse of Class::forName, which
> takes a binary name instead. The note about different class
Hi core-libs-dev,
I know various threads have existed over the past few months on
SequencedCollection and its implications on compatibility. I wanted to
raise this semi-related issue we noticed recently after beginning
testing against Java 21.
Elasticsearch began testing against Java 21, and
On Tue, 27 Jun 2023 14:23:53 GMT, Chen Liang wrote:
>>> What I suggest is to prepare the array only once (in the static block as it
>>> is now), but have each class that use it encapsulate is own copy - obtained
>>> from clone(). Surely 256 shorts is not so large that we can't have two
>>>
On Tue, 27 Jun 2023 14:13:48 GMT, Chen Liang wrote:
>>> > What I suggest is to prepare the array only once (in the static block as
>>> > it is now), but have each class that use it encapsulate is own copy -
>>> > obtained from clone(). Surely 256 shorts is not so large that we can't
>>> >
On Tue, 27 Jun 2023 11:27:18 GMT, 温绍锦 wrote:
>> By optimizing the implementation of java.lang.Long#fastUUID, the performance
>> of the java.util.UUID#toString method can be significantly improved.
>>
>> The following are the test results of JMH:
>>
>> Benchmark Mode Cnt
> This would encourage Classfile API users to use the descriptors as constants,
> which can improve performance by avoiding repeated validation and reusing
> cached descriptor strings for MethodTypeDesc. This patch updates usages in
> the main codebase and benchmarks; tests are left untouched.
1 - 100 of 136 matches
Mail list logo
