> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
On Thu, 16 May 2024 12:35:22 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 204:
>>
>>> 202: new RandomGeneratorProperties(rgClass, name, group,
>>> 203:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision
On Thu, 16 May 2024 10:51:14 GMT, Jaikiran Pai wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Small documentation changes.
>
> test/jdk/java/util/Random/RandomTestCov
On Thu, 16 May 2024 10:33:55 GMT, Jaikiran Pai wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Small documentation changes.
>
> src/java.base/share/classes/java/util/random/Ra
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
On Tue, 14 May 2024 15:40:24 GMT, ExE Boss wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move mathematical logic to record RandomGeneratorProperties.
>
> src/java.base/
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
On Tue, 14 May 2024 11:19:36 GMT, Daniel Fuchs wrote:
>> @dfuch You mean not loading the whole batch but only individual classes, as
>> need arises?
>
> yes - I do not know if loading all the classes in one batch could be an issue
> at startup (I'd expect Random to be loaded early) - but if it
On Mon, 13 May 2024 14:52:45 GMT, Daniel Fuchs wrote:
>> Fine with me.
>
> Not sure if that's an issue - but if you wanted/needed to delay the loading
> of those random generator classes that will not be used until something
> actually wants to use them, you could consider using a `Supplier
On Mon, 13 May 2024 14:08:01 GMT, Jaikiran Pai wrote:
>> Then I would even remove the double-checking idiom, the `volatile` on `ctor`
>> and `properties`, and declare methods `getProperties()` and
>> `ensureConstructors()` as `synchronized`.
>> I'm not sure that the double-checking
On Mon, 13 May 2024 13:41:50 GMT, Jaikiran Pai wrote:
>> All random number generator algorithms are implemented in module
>> `java.base`. The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory`
>> is no longer needed.
>
>
On Mon, 13 May 2024 13:18:24 GMT, Jaikiran Pai wrote:
>> @jaikiran I agree that we can simplify even more. I just wanted to change as
>> little as possible in this PR to facilitate reviews.
>> Shall I push your proposed changes in this PR or is a followup PR preferable?
>
> A followup PR is
On Mon, 13 May 2024 13:06:04 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 190:
>>
>>> 188: if (properties == null) { // double-checking idiom
>>> 189: RandomGeneratorProperties props =
>>>
On Mon, 13 May 2024 08:47:50 GMT, Raffaello Giulietti
wrote:
> All random number generator algorithms are implemented in module `java.base`.
> The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
> needed.
This is a followup of [18932](https://github.com/op
All random number generator algorithms are implemented in module `java.base`.
The usage of `ServiceLoader` in `j.u.r.RandomGeneratorFactory` is no longer
needed.
-
Commit messages:
- 8332086: Remove the usage of ServiceLoader in j.u.r.RandomGeneratorFactory
Changes:
On Fri, 10 May 2024 16:16:18 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 13:39:42 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Fri, 10 May 2024 08:45:32 GMT, Daniel Jeliński wrote:
>> Replace the custom unsigned divide / remainder functions with the
>> compiler-optimized Long.divideUnsigned / remainderUnsigned.
>>
>> No new tests. Existing tier1-3 tests continue to pass.
>>
>> I added a new set of divide
On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti
wrote:
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
This pull request has now been integrated.
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
On Sun, 5 May 2024 05:28:07 GMT, Alan Bateman wrote:
>> 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 merge/rebase. The pull request contains se
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request with a new target base due to
a merge or a rebase. The in
On Tue, 30 Apr 2024 10:21:49 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
> By correctly sizing an intermediate `byte[]` and making use of the internal
> `newStringNoRepl()` method, one allocation per conversion can be avoided when
> the runtime uses compact strings.
Raffaello Giulietti has updated the pull request with a new target base due to
a merge or
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
On Fri, 26 Apr 2024 09:41:21 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
On Fri, 26 Apr 2024 01:35:56 GMT, Joe Darcy wrote:
>> Remove unnecessary setting of variable y, found by an IDE inspection noted
>> in the bug report.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update copyright year.
On Wed, 24 Apr 2024 13:50:56 GMT, Raffaello Giulietti
wrote:
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
In terms of .jmod, the footprint of java.
> Move all random generators mandated in package `java.util.random` and
> currently implemented in module `jdk.random` to module `java.base`, and
> remove module `jdk.random`.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last
Move all random generators mandated in package `java.util.random` and currently
implemented in module `jdk.random` to module `java.base`, and remove module
`jdk.random`.
-
Commit messages:
- 8330005: RandomGeneratorFactory.getDefault() throws exception when the
runtime image only
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, pre-compute
On Mon, 8 Apr 2024 13:46:03 GMT, Roger Riggs wrote:
>> Indeed, different OOMEs are thrown in the two cases triggered by different
>> limits, min +2 is due to integer overflow, while min +1 is due a VM limit
>> on the size of byte[Integer.MAX_VALUE]. Different VM implementations may
>> have
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, pre-compute
On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy wrote:
> Happened to notice a semantic typo in the description of
> MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended,
> and added some additional information to make the related descriptions more
> informative.
Marked as
On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy wrote:
> Happened to notice a semantic typo in the description of
> MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended,
> and added some additional information to make the related descriptions more
> informative.
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.
This pull request has now been integrated.
Changeset: 19a0151a
Author: Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/com
Make use of an unused local variable probably intended to replace later casts.
-
Commit messages:
- 8328700: Unused import and variable should be deleted in regex package
Changes: https://git.openjdk.org/jdk/pull/18460/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18460=00
On Tue, 19 Mar 2024 12:12:30 GMT, Shaojin Wen wrote:
>> I think splitting `CharArraySequence` into two versions is somewhat dubious
>> as more observable types at call sites may mean the performance gain in
>> targeted micros is lost. How much of an improvement did you observe from
>> this?
Vote: yes
On 2024-03-19 16:19, Daniel Fuchs wrote:
Hi,
I hereby nominate Per-Ake Minborg (pminborg) [1] to Membership in the
Core Libraries Group [4].
Per-Ake is an OpenJDK Reviewer, a committer in the
Leyden and Panama projects, and a member of Oracle’s
Java Core Libraries team.
Per-Ake
On Wed, 13 Mar 2024 21:07:54 GMT, Christoph Langer wrote:
>> 4f336085d1098e7fba7b58f0a73c028179a2a13d
>> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
>> cases to test java/util/Formatter/Padding.java with huge Strings as
>> arguments. Since all possible argument
On Wed, 13 Mar 2024 14:10:29 GMT, Christoph Langer wrote:
>> 4f336085d1098e7fba7b58f0a73c028179a2a13d
>> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
>> cases to test java/util/Formatter/Padding.java with huge Strings as
>> arguments. Since all possible argument
On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer wrote:
> 4f336085d1098e7fba7b58f0a73c028179a2a13d
> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
> cases to test java/util/Formatter/Padding.java with huge Strings as
> arguments. Since all possible argument
On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer wrote:
> 4f336085d1098e7fba7b58f0a73c028179a2a13d
> ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few
> cases to test java/util/Formatter/Padding.java with huge Strings as
> arguments. Since all possible argument
On Mon, 11 Mar 2024 17:17:21 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull
On Mon, 11 Mar 2024 14:42:03 GMT, Claes Redestad wrote:
>> Looks great to me. Sorry for the pings, but we may need @rgiulietti to
>> verify the math correctness and @cl4es to comment on whether having these 2
>> separate code paths or trying to extract a common part is the better
>> approach.
On Wed, 6 Mar 2024 20:49:55 GMT, Joe Darcy wrote:
>> The atan2 and hypot cases added would fail for a particular test library
>> that has errors in the millions of ulps for those inputs, rather than the
>> small number of ulps specified for the error.
>
> Joe Darcy has updated the pull request
On Tue, 5 Mar 2024 23:00:16 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>>
On Wed, 28 Feb 2024 00:00:01 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>>
On Fri, 1 Mar 2024 18:01:11 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>>
On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
On Thu, 29 Feb 2024 01:54:54 GMT, Chris Hennick wrote:
>> Chris Hennick has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Bug fix: add-exports was for wrong package
>
> @turbanoff @rgiulietti This is a follow-up to my previously merged
On Tue, 27 Feb 2024 20:37:03 GMT, Chad Rakoczy wrote:
>> The fix in JDK-8299677 serves it's intended purpose but the test added with
>> it does not test that. The original test does not timeout before or after
>> the fix which is the issue.
>>
>> "8326718: Test
On Tue, 27 Feb 2024 19:53:23 GMT, Joe Darcy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>>
On Tue, 27 Feb 2024 19:46:27 GMT, Chad Rakoczy wrote:
>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
>> with Formatter.format taking a long time when there is a lot of padding.
>> This test runs Formatter.format with very large padding. Test fails before
>>
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
On Tue, 27 Feb 2024 06:13:08 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote:
> Widen acceptable error bound of Math.tan to accommodate the worst-case
> observed error which is slightly outside of the allowable range.
Marked as reviewed by rgiulietti (Reviewer).
Checked with high precision math. The bound reported on
On Fri, 27 Oct 2023 12:10:07 GMT, Raffaello Giulietti
wrote:
>> By correctly sizing an intermediate `byte[]` and making use of the internal
>> `newStringNoRepl()` method, one allocation per conversion can be avoided
>> when the runtime uses compact strings.
>
> Raffael
onal
> commits since the last revision:
>
> - Update test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java
>
>Co-authored-by: Raffaello Giulietti
> - Update test/micro/org/openjdk/bench/java/io/ObjectInputStreamTest.java
>
>Co-authored-by:
ional
> commit since the last revision:
>
> Update src/java.base/share/classes/java/io/DataInputStream.java
>
> Co-authored-by: Raffaello Giulietti
Looks fine.
test/micro/org/openjdk/bench/java/io/DataInputStreamTest.java line 2:
> 1: /*
> 2: * Copyright (c) 2020,
On Thu, 15 Feb 2024 10:33: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 one additional
> commit since the last
On Thu, 15 Feb 2024 10:55:38 GMT, Raffaello Giulietti
wrote:
>> The specification is somewhat ambiguous:
>> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/io/DataInput.html#readUTF()
>>
>> There's a sweeping `Throws UTFDataFormatException - if the by
On Wed, 14 Feb 2024 14:30:02 GMT, Claes Redestad wrote:
>> Ah OK.
>>
>> I didn't check the current code, only the proposed one.
>> Although the specification clearly states that the method should throw, if
>> the current code does not throw on zeros, then it makes sense that the
>> proposed
On Wed, 14 Feb 2024 11:29:43 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/io/DataInputStream.java line 604:
>>
>>> 602: // For ASCII ISO-8859-1 is equivalent to UTF-8, while
>>> avoiding a redundant
>>> 603: // scan
>>> 604:
On Tue, 6 Feb 2024 16:17:21 GMT, Claes Redestad wrote:
> Adding a fast-path for ASCII-only modified UTF-8 strings deserialied via
> Data- and ObjectInputStream
>
> Testing: tier1-3
src/java.base/share/classes/java/io/DataInputStream.java line 585:
> 583: DataInputStream dis = null;
>
On Sun, 21 Jan 2024 13:48:49 GMT, Shaojin Wen wrote:
>> @cl4es made performance optimizations for the simple specifiers of
>> String.format in PR https://github.com/openjdk/jdk/pull/2830. Based on the
>> same idea, I continued to make improvements. I made patterns like %2d %02d
>> also be
On Fri, 2 Feb 2024 20:53: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
>>
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 Fri, 2 Feb 2024 16:20:21 GMT, ExE Boss 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 Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZimmermann/papers/accuracy.pdf
>
>
On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 wrote:
>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
>> Hacker's Delight (2nd ed), section 9.3, the same used in
>> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
>> to get the
On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 wrote:
>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
>> Hacker's Delight (2nd ed), section 9.3, the same used in
>> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
>> to get the
On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 wrote:
>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
>> Hacker's Delight (2nd ed), section 9.3, the same used in
>> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
>> to get the
On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 wrote:
>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
>> Hacker's Delight (2nd ed), section 9.3, the same used in
>> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
>> to get the
On Tue, 9 Jan 2024 18:24:49 GMT, fabioromano1 wrote:
>> The method `MutableBigInteger.divWord(long, int)` can use the algorithm of
>> Hacker's Delight (2nd ed), section 9.3, the same used in
>> `Long.divideUnsigned(long, long)` and `Long.remainderUnsigned(long, long)`,
>> to get the
On Fri, 19 Jan 2024 14:14:26 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, 19 Jan 2024 14:10:48 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, 19 Jan 2024 12:26:51 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, 18 Jan 2024 18:50:56 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 coverage,
On Fri, 15 Dec 2023 17:34:53 GMT, Raffaello Giulietti
wrote:
> Adds serialization misdeclaration events to JFR.
This pull request has now been integrated.
Changeset: bfd2afe5
Author: Raffaello Giulietti
URL:
https://git.openjdk.org/jdk/com
On Mon, 15 Jan 2024 14:17:40 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:
>
> Removed useless event sett
> Adds serialization misdeclaration events to JFR.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Removed useless event settings in test.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
-
On Tue, 19 Dec 2023 17:53:49 GMT, Erik Gahlin wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewer's comments.
>
>> You mean, in the @descriptio
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.
On Thu, 11 Jan 2024 10:34:45 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,
> 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.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
- new: ht
On Wed, 10 Jan 2024 16:58:43 GMT, Roger Riggs wrote:
>> I'm not sure that a `native` method is not considered effective by
>> serialization. I have to check.
>
> The spec is silent about methods being 'native'; it would generally be
> impractical to implement native methods for these purposes,
On Wed, 10 Jan 2024 16:55:58 GMT, Roger Riggs wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes according to reviewers feedback.
>
> src/j
On Wed, 10 Jan 2024 16:49:50 GMT, Roger Riggs wrote:
>> Conceptually, these are independent types. There's no logical relationship
>> between them. Sharing a zero length array would convey a false sense of
>> logical sharing.
>
> true, but its wasted space and IMHO ok as a local and private
> 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.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17129/files
-
On Wed, 10 Jan 2024 14:48:21 GMT, Roger Riggs wrote:
>> Pavel Rappo has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 20 commits:
>>
>> - Use Integer.compareUnsigned
>> - Update copyright years and headers
>> - Merge branch
On Tue, 9 Jan 2024 18:31:49 GMT, Daniel Fuchs wrote:
>> Yes, that's perhaps clearer, will do.
>
> Typically in other places in the JDK we use `priviledgedXxx` for naming
> methods that are simple wrappers that call `xxx` from within a
> `doPrivileged`. The method is called privileged because
1 - 100 of 553 matches
Mail list logo
