Re: RFR: 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker
On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti wrote: > These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as > hard test cases. Many of the test cases failed before [PR3402](https://github.com/openjdk/jdk/pull/3402), so it's worth having them in the codebase to detect regressions. - PR: https://git.openjdk.org/jdk/pull/9084
Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti wrote: > This fixes a bug introduced with JDK-8202449. This pull request has now been integrated. Changeset: da2339cf Author: Raffaello Giulietti Committer: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/da2339cf6971532593e4f1b5ebbce8d1ed2e83b2 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html Reviewed-by: bpb, darcy - PR: https://git.openjdk.org/jdk/pull/9120
Re: RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti wrote: > This fixes a bug introduced with JDK-8202449. The fix reverts an inadvertent "correction" sneaked into JDK-8202449, restoring previous (correct) behavior. - PR: https://git.openjdk.org/jdk/pull/9120
Re: RFR: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof
On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy wrote: > There are many instanceof checks in the sun.reflection.annotation code; these > would be improved by using pattern matching for instanceof. Seems clean - PR: https://git.openjdk.org/jdk/pull/9129
RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
This fixes a bug introduced with JDK-8202449. - Commit messages: - 8288173: JDK-8202449 fix causes conformance test failure Changes: https://git.openjdk.org/jdk/pull/9120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9120=00 Issue: https://bugs.openjdk.org/browse/JDK-8288173 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9120.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9120/head:pull/9120 PR: https://git.openjdk.org/jdk/pull/9120
Integrated: 8202449: overflow handling in Random.doubles
On Thu, 19 May 2022 15:54:06 GMT, Raffaello Giulietti wrote: > Extend the range of Random.doubles(double, double) and similar methods. This pull request has now been integrated. Changeset: c8cff1bd Author: Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c8cff1bd6f9807e90a6992ad3e181fe0d94397b8 Stats: 118 lines in 5 files changed: 47 ins; 36 del; 35 mod 8202449: overflow handling in Random.doubles Reviewed-by: darcy - PR: https://git.openjdk.java.net/jdk/pull/8791
Integrated: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)
On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti wrote: > BigDecimal(String) currently fails to accept some strings produced by > BigDecimal.toString(). This PR removes this limitation. This pull request has now been integrated. Changeset: c15e10fb Author:Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/c15e10fb6c35a99e80009f0a7b6a252fcbb549b7 Stats: 70 lines in 2 files changed: 23 ins; 26 del; 21 mod 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) Reviewed-by: darcy - PR: https://git.openjdk.java.net/jdk/pull/8905
RFR: 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker
These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as hard test cases. - Commit messages: - 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker Changes: https://git.openjdk.java.net/jdk/pull/9084/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9084=00 Issue: https://bugs.openjdk.org/browse/JDK-8288021 Stats: 19594 lines in 1 file changed: 19594 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/9084.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9084/head:pull/9084 PR: https://git.openjdk.java.net/jdk/pull/9084
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
Hi, the aim of this PR was firstly to have a correct implementation of the spec. Speed improvement was a secondary goal, which was intentionally pursued with conventional Java arithmetic and just a few calls to simple methods in the standard library. Whether the Vector API (which is still in incubation phase) might help in this specific case remains to be explored. As a first impression, there seem to be no good spots to parallelize using SIMD instructions. But engineers with more SIMD experience might find creative ways to make good use of them. HTH Raffaello On 2022-06-07 18:35, LifeIsStrange wrote: On Mon, 9 May 2022 12:50:31 GMT, Raffaello Giulietti wrote: Marked as reviewed by limck...@github.com (no known OpenJDK username). @limck599 While we at OpenJDK appreciate constructive reviews from GitHub users not registered in the [census](https://openjdk.java.net/census), only officially nominated reviewers have the authority to approve this PR. @rgiulietti friendly ping, noob question: Do you believe some parts of the algorithm could exploit explicit SIMD instructions (via the high level [Vector API](https://openjdk.java.net/jeps/417)) for even better performance (such as https://github.com/wrandelshofer/FastDoubleParser ) ? - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8202449: overflow handling in Random.doubles [v3]
On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti wrote: >> Extend the range of Random.doubles(double, double) and similar methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8202449: overflow handling in Random.doubles Hi, the major code changes are in `RandomSupport` in methods checkRange(float,float) checkRange(double,double) where the checks are more tolerant, and in boundedNextDouble(RandomGenerator,double,double) boundedNextFloat(RandomGenerator,float,float) that extend the accepted range. In case the range size overflows, the methods half the range, generate a value inside the reduced range and finally double the outcome. - PR: https://git.openjdk.java.net/jdk/pull/8791
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) [v2]
On Fri, 27 May 2022 22:59:47 GMT, Raffaello Giulietti wrote: >> BigDecimal(String) currently fails to accept some strings produced by >> BigDecimal.toString(). This PR removes this limitation. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8233760: Result of BigDecimal.toString throws overflow exception on new > BigDecimal(str) Hello, here's an explanation of the changes in `BigDecimal`. Rather than keeping track of a local `int scl` (scale) and a local `long exp` (exponent), the change only keeps track of a `long scl`, adapting it accordingly. It checks the range of `scl` before initializing the fields. This makes for a simpler code. In addition, I couldn't resist changing C-style arrays to Java style over the whole class. - PR: https://git.openjdk.java.net/jdk/pull/8905
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v4]
On Mon, 6 Jun 2022 22:24:03 GMT, Joe Darcy wrote: >> Generally add apiNote's to map from Java library methods to particular IEEE >> 754 operations. For now, I only added such notes to java.lang.Math and not >> java.lang.StrictMath. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. LGTM - PR: https://git.openjdk.java.net/jdk/pull/8876
Re: Questions about Float.toString(float)
On 2022-06-05 09:59, LP wrote: Hi, (1) float f = Float.intBitsToFloat(260046848); JDK 17: Float.toString(f) -> 1.26217745E-29 master: Float.toString(f) -> 1.2621775E-29 BigDecimal.valueOf(Float.intBitsToFloat(260046847)) -> 1.2621773731219804E-29 BigDecimal.valueOf(Float.intBitsToFloat(260046848)) -> 1.2621774483536189E-29 BigDecimal.valueOf(Float.intBitsToFloat(260046849)) -> 1.2621775988168958E-29 What about 1.2621774E-29? I believe both 1.2621774E-29 and 1.2621775E-29 satisfy the Javadoc of Float.toString(float), so maybe it doesn't matter, but 1.2621774E-29 is closer to f. In addition to f above, let float g = Float.intBitsToFloat(260046847); Then f == 1.2621775E-29f -> true g == 1.2621774E-29f -> true Hence, 1.2621774E-29f rounded to the closest float is g, not f. 1.2621775E-29f is indeed the shortest decimal that rounds to f. Other equally long decimals like 1.2621774E-29f or 1.2621776E-29f do not round to f but to other floats. So, no, 1.2621774E-29 does not satisfy the spec for f. Only 1.2621775E-29 does. (2) float f = Float.intBitsToFloat(1291845637); JDK 17: Float.toString(f) -> 1.34217808E8 master: Float.toString(f) -> 1.3421781E8 BigDecimal.valueOf(Float.intBitsToFloat(1291845636)) -> 134217792 BigDecimal.valueOf(Float.intBitsToFloat(1291845637)) -> 134217808 BigDecimal.valueOf(Float.intBitsToFloat(1291845638)) -> 134217824 What about 1.342178E8? 1.3421781E8 is an improvement over 1.34217808E8, but it's still not conforming to the Javadoc if 1.342178E8 is valid. Again, 1.342178E8f < 1.3421781E8f, so these are decimals representing two different floats. Only 1.3421781E8f rounds to your f, whereas 1.342178E8f rounds to float g = Float.intBitsToFloat(1291845636); Apologies if I misunderstood something. Thanks, LP
RFR: [CSR] 8287376: BigDecimal(String) must allow a larger range for the exponent
Hello, anybody willing to review this small CSR? https://bugs.openjdk.java.net/browse/JDK-8287376 Thanks Raffaello
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
On Wed, 1 Jun 2022 08:39:44 GMT, Raffaello Giulietti wrote: > not just ties Plz. disregard this 3 words - PR: https://git.openjdk.java.net/jdk/pull/8876
Integrated: 4511638: Double.toString(double) sometimes produces incorrect results
On Thu, 8 Apr 2021 21:12:21 GMT, Raffaello Giulietti wrote: > Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello This pull request has now been integrated. Changeset: 72bcf2aa Author:Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/72bcf2aa03d53b0f68eb07a902575b4e8628d859 Stats: 4121 lines in 18 files changed: 4001 ins; 46 del; 74 mod 4511638: Double.toString(double) sometimes produces incorrect results Reviewed-by: aturbanov, darcy, bpb - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v15]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/ad146ec4..93711bae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=13-14 Stats: 618 lines in 1 file changed: 1 ins; 0 del; 617 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
On Tue, 31 May 2022 22:11:54 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results > > src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java line 97: > >> 95: private static final int MASK_28 = (1 << 28) - 1; >> 96: >> 97: private static final int NON_SPECIAL= 0; > > As these are shared with `DoubleToDecimal` would these constants be better > moved to a common location, e.g., `MathUtils` whether converted to an `enum` > or not? As long as the values are constant `ints`, moving them to `MathUtils` is less robust. Changing any value would require remembering to recompile the "clients". The move would make sense if these were an enum. - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
On Tue, 31 May 2022 21:55:16 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results > > src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 97: > >> 95: private static final int MASK_28 = (1 << 28) - 1; >> 96: >> 97: private static final int NON_SPECIAL= 0; > > Would these constants be better as an enum? An enum would make much sense if it were used by other parts of the codebase, and then it would be moved to `MathUtils`. This might well happen in the near future, when this code could be enhanced to be used in formatting conversions, like in "`printf()`" and friends. - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
On Wed, 1 Jun 2022 09:21:43 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 118:
>>
>>> 116: private int index;
>>> 117:
>>> 118: private DoubleToDecimal() {
>>
>> Maybe add a comment like
>>
>> /**
>> * Prevent instantiation.
>> */
>>
>> or
>>
>> // Prevent instantiation of this class.
>
> The constructor _is_ invoked, so the comment would be inappropriate.
... but I added a `throw` in the constructor of `MathUtils`
-
PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
On Tue, 31 May 2022 21:57:44 GMT, Brian Burkhalter wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 4511638: Double.toString(double) sometimes produces incorrect results
>
> src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 118:
>
>> 116: private int index;
>> 117:
>> 118: private DoubleToDecimal() {
>
> Maybe add a comment like
>
> /**
> * Prevent instantiation.
> */
>
> or
>
> // Prevent instantiation of this class.
The constructor _is_ invoked, so the comment would be inappropriate.
-
PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
On Tue, 31 May 2022 21:35:08 GMT, Brian Burkhalter wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results > > src/java.base/share/classes/jdk/internal/math/MathUtils.java line 38: > >> 36: * >> 37: * Giulietti, "The Schubfach way to render doubles", >> 38: * >> https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb > > Even though not public, should the reference use the `` tag and > perhaps be in a `@see` annotation? > > @see href=“https://drive.google.com/file/d/1gp5xv4CAa78SVgCeWfGqqI4FfYYYuNFb”> > The Schubfach way to render doubles These references are inside a normal multi-line comment, so I'm not sure that Javadoc or html tags or have a well-defined semantics there. - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
On Wed, 1 Jun 2022 02:05:40 GMT, Joe Darcy wrote: >> Generally add apiNote's to map from Java library methods to particular IEEE >> 754 operations. For now, I only added such notes to java.lang.Math and not >> java.lang.StrictMath. > > Joe Darcy 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 additional commits since > the last revision: > > - Respond to review feedback; make another pass to link methods to IEEE 754 > operations. > - Merge branch 'master' into JDK-8273346 > - Add floor and ceil. > - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math > and StrictMath src/java.base/share/classes/java/lang/Math.java line 823: > 821: * @apiNote > 822: * This method corresponds to the convertTowardPositive operation > 823: * defined in IEEE 754. Probably what is meant is IEEE `convertToIntegerTowardPositive` (not `convertTowardPositive`). However, that's another kind of rounding, which always rounds any non-integral value toward positive infinity, not just ties. This is not what happens with this method. - PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v14]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/31ca4e10..ad146ec4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=12-13 Stats: 19594 lines in 1 file changed: 0 ins; 19594 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8287544: Replace uses of StringBuffer with StringBuilder in java.naming
On Sun, 29 May 2022 21:57:46 GMT, Andrey Turbanov wrote: > StringBuffer is a legacy synchronized class. StringBuilder is a direct > replacement to StringBuffer which generally have better performance. > There are some code that still uses StringBuffer in java.naming which could > be migrated to `StringBuilder`. _not a reviewer_ LGTM - PR: https://git.openjdk.java.net/jdk/pull/8942
Re: RFR: 8287497: Use String.contains() instead of String.indexOf() in java.naming
On Sun, 29 May 2022 14:00:20 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in java.naming still uses old approach with `String.indexOf` to > check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. _(not a reviewer)_ Provided `indexOf() != -1` and `indexOf() >= 0` are equivalent (which should indeed be the case, according to the Javadoc), the changes look good - PR: https://git.openjdk.java.net/jdk/pull/8938
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) [v2]
On Fri, 27 May 2022 20:16:12 GMT, Joe Darcy wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8233760: Result of BigDecimal.toString throws overflow exception on new
>> BigDecimal(str)
>
> test/jdk/java/math/BigDecimal/StringConstructor.java line 69:
>
>> 67: constructWithError("0.01e"+Integer.MIN_VALUE);
>> 68: constructWithError("1e"+((long)Integer.MIN_VALUE-1));
>> 69:
>
> Please add some test cases to demonstrate that the round-tripping that
> previous did not work is functional after the fix.
Tests were added in the new commit.
-
PR: https://git.openjdk.java.net/jdk/pull/8905
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) [v2]
> BigDecimal(String) currently fails to accept some strings produced by > BigDecimal.toString(). This PR removes this limitation. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) - Changes: - all: https://git.openjdk.java.net/jdk/pull/8905/files - new: https://git.openjdk.java.net/jdk/pull/8905/files/e82cece0..2a25c359 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8905=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8905=00-01 Stats: 22 lines in 1 file changed: 21 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8905/head:pull/8905 PR: https://git.openjdk.java.net/jdk/pull/8905
RFR: [CSR] 8287376: BigDecimal(String) must allow a larger range for the exponent
Currently, BigDecimal(String) requires the exponent part to lie in the int range. This CSR [1] removes this limitation, as it otherwise precludes constructing an instance from a string generated by BigDecimal.toString(). Greetings Raffaello [1] https://bugs.openjdk.java.net/browse/JDK-8287376
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)
On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti wrote: > BigDecimal(String) currently fails to accept some strings produced by > BigDecimal.toString(). This PR removes this limitation. This happens because the constructor currently only accepts exponents in the `int` range (more precisely, in the open range (-2^31, 2^31)). It should accept a larger range of exponents, as long as the resulting `BigDecimal` has a scale in the `int` range. - PR: https://git.openjdk.java.net/jdk/pull/8905
RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)
BigDecimal(String) currently fails to accept some strings produced by BigDecimal.toString(). This PR removes this limitation. - Commit messages: - 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) Changes: https://git.openjdk.java.net/jdk/pull/8905/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8905=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8233760 Stats: 48 lines in 2 files changed: 2 ins; 26 del; 20 mod Patch: https://git.openjdk.java.net/jdk/pull/8905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8905/head:pull/8905 PR: https://git.openjdk.java.net/jdk/pull/8905
Re: RFR: [CSR] 8287026: Changes related to overflow handling in Random.doubles
Sorry, it's the other way round! To bring the spec in sync with the extended behavior of the PR [2] From: core-libs-dev on behalf of Raffaello Giulietti Date: Wednesday, 25 May 2022 at 18:57 To: core-libs-dev@openjdk.java.net Subject: RFR: [CSR] 8287026: Changes related to overflow handling in Random.doubles Please review this CSR [1], whose aim is to bring the extended behavior of the PR [2] in sync with the spec. Greetings Raffaello [1] https://bugs.openjdk.java.net/browse/JDK-8287026 [2] https://git.openjdk.java.net/jdk/pull/8791
RFR: [CSR] 8287026: Changes related to overflow handling in Random.doubles
Please review this CSR [1], whose aim is to bring the extended behavior of the PR [2] in sync with the spec. Greetings Raffaello [1] https://bugs.openjdk.java.net/browse/JDK-8287026 [2] https://git.openjdk.java.net/jdk/pull/8791
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
When they return, these methods meet the property, even for -0.0 provided the underlying eq is floating-point ==, not *::compare: -0.0 -> 0 -> 0.0 and there is a loss of information about the sign bit. However, as currently stated, the property is not 100% correct. For example, (long) (double) Long.MAX_VALUE == Long.MAX_VALUE evaluates to true but you cannot conclude that Long.MAX_VALUE is converted exactly to a double: indeed, it is not. The methods deal with these special cases and throw. The tests for pattern matching should deal with special cases as well. From: Brian Goetz Date: Wednesday, 25 May 2022 at 17:18 To: Raffaello Giulietti , core-libs-dev@openjdk.java.net Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts Another way to evaluate answers here is: are we inventing new relations, or merely clarifying old ones? The latter is often more desirable. For example, we might say that x:X can be converted exactly to Y, for primitive X and Y, iff: eq( (X) (Y) x, x ) where `eq` is `==` for non-floating primitive types, and derived from Float::compare and Double::compare for floating point. This means we are not inventing any new conversions or comparisons, but merely combining ones we already have in the language/platform in a convenient way. Do the toXExact methods you've defined have this characteristic? (Though, while this is often the best starting place, it is not always a slam-dunk answer; sometimes there are good reasons to depart from existing relations, but we should be explicit about what those are.) On 5/25/2022 9:46 AM, Raffaello Giulietti wrote: The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code. But I get your point that having non-throwing tests better serves pattern matching. However, I’m not sure that pattern matching alone would remove the more general need for the proposed methods. As for the controversial question about -0.0, as you note any proposal will kind of suck. With “safer” cast methods we can have two (or even more) variants. In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether. Thus, while examples like if (anIntExpression instanceof byte b) and if (aDoubleExpression instanceof float f) make perfect sense, would an example like if (aDoubleExpression instanceof short s) be pragmatically reasonable? IIRC, the discussions about “Primitive type patterns” and “Evolving past reference type patterns” in the amber-spec-experts mailing list of April 2022 don’t even mention the mixed integral/floating-point case. Greetings Raffaello From: core-libs-dev <mailto:core-libs-dev-r...@openjdk.java.net> on behalf of Brian Goetz <mailto:brian.go...@oracle.com> Date: Tuesday, 24 May 2022 at 00:09 To: Raffaello Giulietti <mailto:d...@openjdk.java.net>, core-libs-dev@openjdk.java.net<mailto:core-libs-dev@openjdk.java.net> <mailto:core-libs-dev@openjdk.java.net> Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But sur
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
The motivation behind this PR is not driven by pattern matching: John Rose (the reporter of the JBS issue) is concerned about having safer casts that, in addition, can be JITted to efficient code. But I get your point that having non-throwing tests better serves pattern matching. However, I’m not sure that pattern matching alone would remove the more general need for the proposed methods. As for the controversial question about -0.0, as you note any proposal will kind of suck. With “safer” cast methods we can have two (or even more) variants. In the context of primitive pattern matching (including the relevant material in the JLS), however, it would be probably much simpler to allow for matches between integral types on one side and for matches between floating-point types on the other side, but not a mix. The nuisance with -0.0 and other special values would disappear altogether. Thus, while examples like if (anIntExpression instanceof byte b) and if (aDoubleExpression instanceof float f) make perfect sense, would an example like if (aDoubleExpression instanceof short s) be pragmatically reasonable? IIRC, the discussions about “Primitive type patterns” and “Evolving past reference type patterns” in the amber-spec-experts mailing list of April 2022 don’t even mention the mixed integral/floating-point case. Greetings Raffaello From: core-libs-dev on behalf of Brian Goetz Date: Tuesday, 24 May 2022 at 00:09 To: Raffaello Giulietti , core-libs-dev@openjdk.java.net Subject: Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts This work is quite timely as we are now paving the way for primitive type patterns over in Project Amber, and also has a nontrivial connection with Valhalla. If you'll pardon a brief digression... Instanceof and casting work together in a familiar way: before you cast, you first ask instanceof -- but this is restricted currently to reference types. But the pattern is obvious: instanceof is the precondition check for casting, which asks: "If I made this cast, would I like the answer." There are currently two reasons to not like the answer: a CCE, or the operand is null (because, even though the cast would succeed, if you tried to use it as a member of that type, you wouldn't like the answer then.) If we wanted to extend `instanceof` to primitive types, we are asking the same question: if I were to cast to this type, would I like the answer. And casts involving primitives give us two more reasons to not like the answer: an NPE (due to unboxing), or loss of precision. Which means that we have to specify in JLS 5.1 what cast with loss of precision means. At the very least, we will want to align this work with that; the asXExact should be able to say "throws if the cast would lose precision", where "lose precision" is precisely defined by the JLS. Separately, Project Valhalla will let us define new primitive-like types, such as HalfFloat and SuperLong. Conversions between primitives are currently specified in a complex table in JLS 5.1. But surely we will want to support primitive widening conversions between HalfFloat and float (somehow; how we do this is a separate discussion.) Which brings us back to pattern matching; narrowing casts are inherently partial, and declared patterns bring partiality into the "return type", and are the natural way (when we have it) to express things like "cast, but fail if you can't do so safely". This is preferable to throwing (which currently is the our choice.) So it might be a little unfortunate to introduce throwing toXExactly now and then have to introduce separate patterns which signal precision loss by match failure. (Though that's not the end of the world if there is some duplication.) What this says is that the current proposal of toXExact is not the primitive, because we probably wouldn't want to implement a pattern in terms of the throwing version. Converting from float/double to integral types is particularly tricky with -0.0. Both answers kind of suck. (This is a familiar situation, and these can be very difficult to resolve, as for each position, *someone* has decided the other position is untenable.) I understand the rationale behind Michael H's "but its not exact", but let's not pretend one answer is good and the other sucks -- they both suck, and therefore the decision can be made on other factors. So I have a few new wrinkles to add to the story: - We should wait until we have candidate JLS text for "cast conversion without loss of precision", and ensure the two are consistent, before pushing; - I not quite comfortable with settling the -0.0 issue just yet, there are some other explorations to complete first; - We should be prepared for the fact that we will, sometime soon, have to implement this whole set again as patterns that do not throw. On 5/5/2022 6:1
Re: RFR: 8202449: overflow handling in Random.doubles [v3]
On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti wrote: >> Extend the range of Random.doubles(double, double) and similar methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8202449: overflow handling in Random.doubles `Random.doubles(double, double)` and similar methods depend on `RandomGenerator.nextDouble(double, double)`. Currently, this method is specified to throw when the range [origin, bound) given by the arguments is so large that its size (bound - origin) overflows. Since the proposed implementation doesn't suffer from this limitation, the specification needs to be modified, thus the need for a CSR. - PR: https://git.openjdk.java.net/jdk/pull/8791
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v6]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/5fb1fed4..4cf9a8cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=04-05 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations
On Wed, 25 May 2022 00:19:41 GMT, Joe Darcy wrote:
> Generally add apiNote's to map from Java library methods to particular IEEE
> 754 operations. For now, I only added such notes to java.lang.Math and not
> java.lang.StrictMath.
src/java.base/share/classes/java/lang/Math.java line 771:
> 769: * This method corresponds to the convertToIntegerTiesToEven
> 770: * operation defined in IEEE 754.
> 771: *
IEEE `convertToIntegerTiesToEven` rounds ties to the even integer.
The method's spec, however, requires ties to round toward positive infinity.
Unfortunately, IEEE 754 doesn't offer a `convertToIntegerTiesToPositive`
src/java.base/share/classes/java/lang/Math.java line 824:
> 822: * This method corresponds to the convertToIntegerTiesToEven
> 823: * operation defined in IEEE 754.
> 824: *
see comment for `round(float)`
src/java.base/share/classes/java/math/RoundingMode.java line 49:
> 47: * exponent range of {@code BigDecimal}, the mathematical result will
> 48: * be exactly representable in the result precision or fall between
> 49: * two representable values. In the case of falling between two
Perhaps better would be
`two adjacent representable values.`
-
PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8202449: overflow handling in Random.doubles [v3]
> Extend the range of Random.doubles(double, double) and similar methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8202449: overflow handling in Random.doubles - Changes: - all: https://git.openjdk.java.net/jdk/pull/8791/files - new: https://git.openjdk.java.net/jdk/pull/8791/files/62322ac1..954d1ea2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8791=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8791=01-02 Stats: 21 lines in 2 files changed: 0 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791 PR: https://git.openjdk.java.net/jdk/pull/8791
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v5]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/f629f5b3..5fb1fed4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v4]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/5f0ff527..f629f5b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=02-03 Stats: 201 lines in 1 file changed: 196 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8284493: Fix rounding error in computeNextExponential
On Sun, 22 May 2022 20:19:38 GMT, Andrey Turbanov wrote: >> Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a >> rounding error to accumulate at the tail of the distribution (probably >> starting around 2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1); this fixes >> that by tracking the multiple of exponentialX0 as a long. (This changes the >> maximum possible output to `1.0p63 * DoubleZigguratTables.exponentialX0 == >> 0x1.e46eff20739afp65`; previously it would have been `0x1.0p56` because once >> `extra` reaches that amount, `x + extra == extra` due to the rounding error. >> This lowers the probability of reaching the maximum with an ideal PRNG from >> about `1.3877787807814488E-17` to about `1.4323726067488646E-20` (calculated >> using the identity `ln(x) == Math.log10(x)/Math.log10(Math.exp(1))`). > > src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line > 1411: > >> 1409: long U2 = (rng.nextLong() >>> 1); >> 1410: // Compute the actual x-coordinate of the randomly >> chosen point. >> 1411: x = Math.fma(X[j-1] - X[j], (double)U1, X[j] * >> 0x1.0p63)); > > Code is not compilable @Pr0methean As @turbanoff observes, I think there's a closing parentheses too much on L.1411 and one on L.1421. Which compiler are you using ;-) ? - PR: https://git.openjdk.java.net/jdk/pull/8131
Re: RFR: 8202449: overflow handling in Random.doubles [v2]
> Extend the range of Random.doubles(double, double) and similar methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8202449: overflow handling in Random.doubles - Changes: - all: https://git.openjdk.java.net/jdk/pull/8791/files - new: https://git.openjdk.java.net/jdk/pull/8791/files/936a5bc1..62322ac1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8791=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8791=00-01 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791 PR: https://git.openjdk.java.net/jdk/pull/8791
RFR: 8202449: overflow handling in Random.doubles
Extend the range of Random.doubles(double, double) and similar methods. - Commit messages: - 8202449: overflow handling in Random.doubles Changes: https://git.openjdk.java.net/jdk/pull/8791/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8791=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8202449 Stats: 108 lines in 4 files changed: 47 ins; 25 del; 36 mod Patch: https://git.openjdk.java.net/jdk/pull/8791.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8791/head:pull/8791 PR: https://git.openjdk.java.net/jdk/pull/8791
Integrated: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts
On Mon, 16 May 2022 14:48:43 GMT, Raffaello Giulietti wrote: > Please review these simple changes in jdk.internal.math.[Double|Float]Consts This pull request has now been integrated. Changeset: ea713c37 Author: Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/ea713c37fb7eb628c46ad8838425a0029f24be9d Stats: 41 lines in 2 files changed: 12 ins; 5 del; 24 mod 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts Reviewed-by: bpb, rriggs, darcy - PR: https://git.openjdk.java.net/jdk/pull/8729
Re: RFR: 8213045: Add BigDecimal.TWO [v2]
On Mon, 16 May 2022 22:34:21 GMT, Brian Burkhalter wrote: >> Add constant `java.math.BigDecimal.TWO`. > > Brian Burkhalter has refreshed the contents of this pull request, and > previous commits have been removed. The incremental views will show > differences compared to the previous content of the PR. The pull request > contains one new commit since the last revision: > > 8213045: Add BigDecimal.TWO Looks good - PR: https://git.openjdk.java.net/jdk/pull/8735
Re: RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts [v3]
> Please review these simple changes in jdk.internal.math.[Double|Float]Consts Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8729/files - new: https://git.openjdk.java.net/jdk/pull/8729/files/3c6be86c..af257f81 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8729=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8729=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729 PR: https://git.openjdk.java.net/jdk/pull/8729
Re: RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts [v2]
On Mon, 16 May 2022 15:54:25 GMT, Raffaello Giulietti wrote: >> Please review these simple changes in jdk.internal.math.[Double|Float]Consts > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8286810: Use public [Double|Float].PRECISION fields in > jdk.internal.math.[Double|Float]Consts Will wait 24 hours before integrating - PR: https://git.openjdk.java.net/jdk/pull/8729
Re: RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts
On Mon, 16 May 2022 14:48:43 GMT, Raffaello Giulietti wrote: > Please review these simple changes in jdk.internal.math.[Double|Float]Consts Adjusted - PR: https://git.openjdk.java.net/jdk/pull/8729
Re: RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts [v2]
> Please review these simple changes in jdk.internal.math.[Double|Float]Consts Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8729/files - new: https://git.openjdk.java.net/jdk/pull/8729/files/0091e546..3c6be86c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8729=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8729=00-01 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729 PR: https://git.openjdk.java.net/jdk/pull/8729
RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts
Please review these simple changes in jdk.internal.math.[Double|Float]Consts - Commit messages: - 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts Changes: https://git.openjdk.java.net/jdk/pull/8729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8729=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286810 Stats: 37 lines in 2 files changed: 8 ins; 5 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/8729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8729/head:pull/8729 PR: https://git.openjdk.java.net/jdk/pull/8729
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v13]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/b40d7e80..31ca4e10 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=11-12 Stats: 54 lines in 4 files changed: 0 ins; 0 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF [v3]
On Thu, 12 May 2022 16:01:50 GMT, Brian Burkhalter wrote: >> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to >> indicate that `-1` is returned at the EOF of the last stream even if `len` >> is zero. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8286200: Change @throws NPE clause of read(byte[],int,int) to better match > specification verbiage _(not a reviewer)_ Looks good - Marked as reviewed by rgiulie...@github.com (no known OpenJDK username). PR: https://git.openjdk.java.net/jdk/pull/8664
Re: RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF [v2]
On Thu, 12 May 2022 15:48:47 GMT, Brian Burkhalter wrote: >> Modify the specification of `SequenceInputStream.read(byte[],int,int)` to >> indicate that `-1` is returned at the EOF of the last stream even if `len` >> is zero. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8286200: Change @throws IOOBE clause of read(byte[],int,int) to better > match specification verbiage I think the same change shall apply to the `@throws NullPointerException` clause. - PR: https://git.openjdk.java.net/jdk/pull/8664
Re: RFR: 8286200: SequenceInputStream::read(b, off, 0) returns -1 at EOF
On Wed, 11 May 2022 20:47:52 GMT, Brian Burkhalter wrote: > Modify the specification of `SequenceInputStream.read(byte[],int,int)` to > indicate that `-1` is returned at the EOF of the last stream even if `len` is > zero. Also, in the current implementation, when the end of the last contained stream has been reached and `-1` is returned, none of the arguments is checked, so a caller can pass `null` for `b` or out of bounds indices `off` and `len`. This is at odd with the `@throws` clauses. - PR: https://git.openjdk.java.net/jdk/pull/8664
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v12]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/907abfd6..b40d7e80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=10-11 Stats: 28 lines in 7 files changed: 0 ins; 9 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
On Tue, 10 May 2022 03:22:01 GMT, Joe Darcy wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results > > src/java.base/share/classes/java/lang/Double.java line 33: > >> 31: import java.util.Optional; >> 32: >> 33: import jdk.internal.math.FloatingDecimal; > > Presumably the FloatingDecimal import here and in Float can be removed. `FloatingDecimal` is used in the `parse*(String)` methods - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
On Tue, 10 May 2022 03:21:21 GMT, Joe Darcy wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 4511638: Double.toString(double) sometimes produces incorrect results
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 882:
>
>> 880: try {
>> 881: FloatToDecimal.appendTo(f, this);
>> 882: } catch (IOException ignored) {
>
> What is the motivation for wrapping with IOException?
`[Float|Double]ToDecimal` do not have access to `AbstractStringBuilder`, so
have to fail over `Appendable`, which can throw `IOException` in `append(*)`
methods.
I have to find another way if this wrapping to make the compiler happy is
unacceptable.
-
PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v3]
> Add a family of "safe" cast methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/7be0f9de..5f0ff527 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=01-02 Stats: 35 lines in 2 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Tue, 10 May 2022 04:42:19 GMT, Joe Darcy 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 four
>> additional commits since the last revision:
>>
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>>
>>Merge branch 'master' into JDK-8279986
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>>
>>Merge branch 'master' into JDK-8279986
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>> - 8279986: methods Math::asXExact for safely checked primitive casts
>
> src/java.base/share/classes/java/lang/Math.java line 1578:
>
>> 1576: */
>> 1577: @ForceInline
>> 1578: public static long toUnsignedIntExact(long value) {
>
> Existing methods like Integer.parseUnsignedInt interpret the negative int
> values as positive values larger than MAX_INT. So if an int is not going to
> be returned here, I suggest a name like "toUnsignedIntRangeExact".
Returning a `long` is probably less error prone.
When the result is to be used in an `int` context, one simply has to add a
`(int)` cast, as mandated by language, compiler and IDE.
On the other hand, if this method were to return an `int`, when using the
result in a `long` context one has to remember masking it with `0x_L`.
AFAIK, there's no compiler or IDE support for this.
The name `toUnsignedIntRangeExact` is certainly better.
-
PR: https://git.openjdk.java.net/jdk/pull/8548
Integrated: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]
On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti wrote: > Please review these small changes to address intermittent failures, as of > JDK-8274517. > > - Usage of jdk.test.lib.RandomFactory for reproducible random generation. > - Slightly less restrictive assertion about badParallelStreamError on L94 > (former L88). > - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. > > While these changes do not necessarily guarantee absence of intermittent > failures, the usage of jdk.test.lib.RandomFactory should at least help to pin > down specific double sequences that do not pass the test. > > There is still an inherent variability due to the use of parallel streams, > though. As double addition is not perfectly associative, even a fully known > sequence of doubles may lead to slightly different results with > parallelization. This pull request has now been integrated. Changeset: 97a98352 Author:Raffaello Giulietti Committer: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/97a983526b41d26fcd1caa162a089690119874b0 Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] Reviewed-by: alanb, bpb - PR: https://git.openjdk.java.net/jdk/pull/8290
Re: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] [v2]
On Mon, 9 May 2022 09:25:15 GMT, Raffaello Giulietti wrote: >> Please review these small changes to address intermittent failures, as of >> JDK-8274517. >> >> - Usage of jdk.test.lib.RandomFactory for reproducible random generation. >> - Slightly less restrictive assertion about badParallelStreamError on L94 >> (former L88). >> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. >> >> While these changes do not necessarily guarantee absence of intermittent >> failures, the usage of jdk.test.lib.RandomFactory should at least help to >> pin down specific double sequences that do not pass the test. >> >> There is still an inherent variability due to the use of parallel streams, >> though. As double addition is not perfectly associative, even a fully known >> sequence of doubles may lead to slightly different results with >> parallelization. > > 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 two additional > commits since the last revision: > > - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with >expected [true] but found [false] > >Merge branch 'master' into JDK-8274517 > - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with > expected [true] but found [false] After a post Loom merge, this PR lost its _sponsor_ label, so I had to integrate again. No changes w.r.t. the previous commit. - PR: https://git.openjdk.java.net/jdk/pull/8290
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
On Mon, 9 May 2022 12:34:20 GMT, limck599 wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 4511638: Double.toString(double) sometimes produces incorrect results > > Marked as reviewed by limck...@github.com (no known OpenJDK username). @limck599 While we at OpenJDK appreciate constructive reviews from GitHub users not registered in the [census](https://openjdk.java.net/census), only officially nominated reviewers have the authority to approve this PR. - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v10]
On Mon, 9 May 2022 09:26:20 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about >> multi-line (block) comments. Nothing in the code proper has changed, except >> for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due > to a merge or a rebase. The pull request now contains 16 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Enhanced intervals in MathUtils. >Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) > comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > >Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - ... and 6 more: > https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15 Getting rid of ThreadLocal - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/bd323d15..907abfd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=09-10 Stats: 30 lines in 2 files changed: 2 ins; 24 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti wrote: >> Add a family of "safe" cast methods. > > 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 four additional > commits since the last revision: > > - 8279986: methods Math::asXExact for safely checked primitive casts > >Merge branch 'master' into JDK-8279986 > - 8279986: methods Math::asXExact for safely checked primitive casts > >Merge branch 'master' into JDK-8279986 > - 8279986: methods Math::asXExact for safely checked primitive casts > - 8279986: methods Math::asXExact for safely checked primitive casts Post Loom merge - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] [v2]
On Mon, 9 May 2022 09:25:15 GMT, Raffaello Giulietti wrote: >> Please review these small changes to address intermittent failures, as of >> JDK-8274517. >> >> - Usage of jdk.test.lib.RandomFactory for reproducible random generation. >> - Slightly less restrictive assertion about badParallelStreamError on L94 >> (former L88). >> - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. >> >> While these changes do not necessarily guarantee absence of intermittent >> failures, the usage of jdk.test.lib.RandomFactory should at least help to >> pin down specific double sequences that do not pass the test. >> >> There is still an inherent variability due to the use of parallel streams, >> though. As double addition is not perfectly associative, even a fully known >> sequence of doubles may lead to slightly different results with >> parallelization. > > 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 two additional > commits since the last revision: > > - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with >expected [true] but found [false] > >Merge branch 'master' into JDK-8274517 > - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with > expected [true] but found [false] Post Loom merge - PR: https://git.openjdk.java.net/jdk/pull/8290
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v10]
On Mon, 9 May 2022 09:26:20 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about >> multi-line (block) comments. Nothing in the code proper has changed, except >> for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due > to a merge or a rebase. The pull request now contains 16 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Enhanced intervals in MathUtils. >Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > >Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > >Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) > comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > >Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - ... and 6 more: > https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15 Post Loom merge - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
> Add a family of "safe" cast methods. 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 four additional commits since the last revision: - 8279986: methods Math::asXExact for safely checked primitive casts Merge branch 'master' into JDK-8279986 - 8279986: methods Math::asXExact for safely checked primitive casts Merge branch 'master' into JDK-8279986 - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts - Changes: - all: https://git.openjdk.java.net/jdk/pull/8548/files - new: https://git.openjdk.java.net/jdk/pull/8548/files/4d0924c5..7be0f9de Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8548=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8548=00-01 Stats: 103190 lines in 1255 files changed: 93727 ins; 4219 del; 5244 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v10]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Adapted hashes in ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Enhanced intervals in MathUtils. Updated references to Schubfach v4. - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - ... and 6 more: https://git.openjdk.java.net/jdk/compare/d4474b58...bd323d15 - Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3402=09 Stats: 23708 lines in 16 files changed: 23625 ins; 46 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] [v2]
> Please review these small changes to address intermittent failures, as of > JDK-8274517. > > - Usage of jdk.test.lib.RandomFactory for reproducible random generation. > - Slightly less restrictive assertion about badParallelStreamError on L94 > (former L88). > - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. > > While these changes do not necessarily guarantee absence of intermittent > failures, the usage of jdk.test.lib.RandomFactory should at least help to pin > down specific double sequences that do not pass the test. > > There is still an inherent variability due to the use of parallel streams, > though. As double addition is not perfectly associative, even a fully known > sequence of doubles may lead to slightly different results with > parallelization. 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 two additional commits since the last revision: - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] Merge branch 'master' into JDK-8274517 - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] - Changes: - all: https://git.openjdk.java.net/jdk/pull/8290/files - new: https://git.openjdk.java.net/jdk/pull/8290/files/769855cd..6035eeab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8290=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8290=00-01 Stats: 154484 lines in 2948 files changed: 127735 ins; 11899 del; 14850 mod Patch: https://git.openjdk.java.net/jdk/pull/8290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8290/head:pull/8290 PR: https://git.openjdk.java.net/jdk/pull/8290
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v9]
On Fri, 6 May 2022 08:40:40 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about >> multi-line (block) comments. Nothing in the code proper has changed, except >> for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Match the CSR Updated Schubfach writing URL - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v9]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/904ba115..e7c4bd25 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=07-08 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v8]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 4511638: Double.toString(double) sometimes produces incorrect results - Changes: - all: https://git.openjdk.java.net/jdk/pull/3402/files - new: https://git.openjdk.java.net/jdk/pull/3402/files/a36ff8ac..904ba115 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3402=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3402=06-07 Stats: 389 lines in 5 files changed: 40 ins; 216 del; 133 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v7]
> Hello, > > here's a PR for a patch submitted on March 2020 > [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a > thing. > > The patch has been edited to adhere to OpenJDK code conventions about > multi-line (block) comments. Nothing in the code proper has changed, except > for the addition of redundant but clarifying parentheses in some expressions. > > > Greetings > Raffaello Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Adapted hashes in ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Enhanced intervals in MathUtils. Updated references to Schubfach v4. - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. - 4511638: Double.toString(double) sometimes produces incorrect results Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java - 4511638: Double.toString(double) sometimes produces incorrect results Merge branch 'master' into JDK-4511638 - 4511638: Double.toString(double) sometimes produces incorrect results - 4511638: Double.toString(double) sometimes produces incorrect results Refactored test classes to better match OpenJDK conventions. Added tests recommended by Guy Steele and Paul Zimmermann. - ... and 3 more: https://git.openjdk.java.net/jdk/compare/dd06cc63...a36ff8ac - Changes: https://git.openjdk.java.net/jdk/pull/3402/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3402=06 Stats: 23938 lines in 16 files changed: 23809 ins; 54 del; 75 mod Patch: https://git.openjdk.java.net/jdk/pull/3402.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3402/head:pull/3402 PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 15:07:32 GMT, Michael Hixson wrote: > Rationale: It loses information. It truncates the sign, so the value can't be > round-tripped. I think it would be the only lossy transformation permitted by > the to*Exact methods? Right. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. The JLS specifies that the cast (officially, "narrowing primitive conversion") (long)-0.0 returns 0L. As these methods are meant to be safer casts, I think we should follow the JLS as closely as possible. Besides, throwing on -0.0 would make the implementation slightly more convoluted. We want C2 to emit efficient inlineable code. So, what is the use case or the rationale for throwing on -0.0? - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]
On Tue, 19 Apr 2022 08:40:51 GMT, Raffaello Giulietti wrote: > Please review these small changes to address intermittent failures, as of > JDK-8274517. > > - Usage of jdk.test.lib.RandomFactory for reproducible random generation. > - Slightly less restrictive assertion about badParallelStreamError on L94 > (former L88). > - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. > > While these changes do not necessarily guarantee absence of intermittent > failures, the usage of jdk.test.lib.RandomFactory should at least help to pin > down specific double sequences that do not pass the test. > > There is still an inherent variability due to the use of parallel streams, > though. As double addition is not perfectly associative, even a fully known > sequence of doubles may lead to slightly different results with > parallelization. Anybody interested in reviewing? - PR: https://git.openjdk.java.net/jdk/pull/8290
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts
On Thu, 5 May 2022 10:11:05 GMT, Raffaello Giulietti wrote: > Add a family of "safe" cast methods. For an in-depth rationale, please refer to the issue (Enhancement). Note that the method names are, in fact, of the to*Exact rather than of the as*Exact form - PR: https://git.openjdk.java.net/jdk/pull/8548
RFR: 8279986: methods Math::asXExact for safely checked primitive casts
Add a family of "safe" cast methods. - Commit messages: - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts - 8279986: methods Math::asXExact for safely checked primitive casts Changes: https://git.openjdk.java.net/jdk/pull/8548/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8548=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279986 Stats: 615 lines in 2 files changed: 609 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8548.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8548/head:pull/8548 PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: JDK-8285977: Add links to IEEE 754 specification
On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy wrote: > Please review the addition of @-see links from classes that mention the IEEE > 754 floating-point standard to an IEEE page about the standard. The URL in > the initial version of the PR is the top search result on the IEEE home page > for "754 standard". > > Another candidate page to use is > > https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 > > which is (apparently) a stable citation page for the standard. > > These links may be upgraded to the the forthcoming @-spec facility in the > future. ( JDK-6251738). The DOI URL currently brings you to exactly the same IEEExplore page. - PR: https://git.openjdk.java.net/jdk/pull/8511
Re: RFR: JDK-8285977: Add links to IEEE 754 specification
On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy wrote: > Please review the addition of @-see links from classes that mention the IEEE > 754 floating-point standard to an IEEE page about the standard. The URL in > the initial version of the PR is the top search result on the IEEE home page > for "754 standard". > > Another candidate page to use is > > https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 > > which is (apparently) a stable citation page for the standard. > > These links may be upgraded to the the forthcoming @-spec facility in the > future. ( JDK-6251738). What about the DOI URL? Probably even more stable. https://doi.org/10.1109/IEEESTD.2019.8766229 - PR: https://git.openjdk.java.net/jdk/pull/8511
Re: OpenJDK or SE Java Floating Point Options?
>> May the Java Community Process reconsider the present floating point >> operations [...]? Over the past several weeks, this community has unanimously replied to your concerns with a clear: "No thanks, for the next decades we aren't interested in changing the current semantics of floating-point arithmetic in Java." The good news for you: you don't need to spend even more of your time on this mailing list, trying to convince this reluctant community. From: core-libs-dev on behalf of sminervini.prism Date: Monday, 02 May 2022 at 08:58 To: core-libs-dev@openjdk.java.net Subject: OpenJDK or SE Java Floating Point Options? To core-libs-dev, and Glavo, this inner nature of C++, simply means that the floating point equation can be altered in the decimal direction; the beginning of value degredation could be altered in the equation to be entirely outside number type's the range. C++'s "apparent floating point" and SSE, and SSE descendents, are still a solution to look for which I suggest to OpenJDK and JCP. It is still the case that I and others need Java floating point and StrictMath (the key double type calculator class) to be repaired of their denormal and pronormal errors and the circumstances creating such. Such repair is possible, using an SSE oriented approach, while maintaining the current ranges of float and double. Their ranges seem to be: float: from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative). double: from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative). As I attempted to submit in my previous message to core-libs-dev, IEEE 754 is silent on pertinent matters around floating point arithmetic, mainly certain end facts concluding binary and decimal use in computer software; the need to have range objectivity. The proper precedent to draw from is not a standard with a small "blind spot", due to reciprocal exponential terms alone, but the phenomenon which simply states that both information and behaviour can be encoded into a computer, so that such a machine will behave by means of that information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans. Range any decimal mathematics, including floating point, should be for humans, and binary mathematics is for computers. Therefore, for any decimal result to have proper meaning, it must be entirely correct within its (rational, truncated) range. The most meaningfull thing to do, while creating the least number of language disturbances, is to utilise additional (SEE and similar) registers, with appropriate sub-java (implementation) code, to use all registry space, including the extra space if needed, to produce range accurate Java results via improved operational logic. It is known that having a little more registry space past the number (result range) limit, for use and consideration, is the only range, base-10 perfect way to go. It is certainly better than the available class approaches, which waste memory, speed, and lack important and appropriate auxiliary use options. It is also the case that asymptotic number generation from the floating point equation that Java uses can be offset to occur outside of the end point of the decimal values range end. May the Java Community Process reconsider the present floating point operations and method calls situation, based on an imperfect standard and improper operation improper and workarounds, and provide corrected, defaulting or specified compatible ways for Java floating point arithmetic and Calculator class method results to always cohere in their ranges, without denormal and pronormal inclusions whatsoever?
Integrated: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
On Tue, 26 Apr 2022 16:38:37 GMT, Raffaello Giulietti wrote: > The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. This pull request has now been integrated. Changeset: 1f868f1d Author:Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/1f868f1d091602cc462ee0fe5fa613a3638a5f1c Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod 8285658: Fix two typos in the spec of j.u.random.RandomGenerator Reviewed-by: bpb, darcy - PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v3]
> The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8404/files - new: https://git.openjdk.java.net/jdk/pull/8404/files/8d4388bd..b33cfa30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8404=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8404=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404 PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator [v2]
> The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator - Changes: - all: https://git.openjdk.java.net/jdk/pull/8404/files - new: https://git.openjdk.java.net/jdk/pull/8404/files/b3a802ae..8d4388bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8404=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8404=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404 PR: https://git.openjdk.java.net/jdk/pull/8404
Re: RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
On Tue, 26 Apr 2022 16:38:37 GMT, Raffaello Giulietti wrote: > The spec of the interface `java.util.random.RandomGenerator` is slightly > incorrect when it discusses `float` and `double` random values. This PR fixes the spec and replaces hard-coded literals with static compilation time symbolic expressions. - PR: https://git.openjdk.java.net/jdk/pull/8404
RFR: 8285658: Fix two typos in the spec of j.u.random.RandomGenerator
The spec of the interface `java.util.random.RandomGenerator` is slightly incorrect when it discusses `float` and `double` random values. - Commit messages: - Fix two typos in the spec of j.u.random.RandomGenerator Changes: https://git.openjdk.java.net/jdk/pull/8404/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8404=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285658 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8404.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8404/head:pull/8404 PR: https://git.openjdk.java.net/jdk/pull/8404
Integrated: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
On Fri, 22 Apr 2022 14:26:07 GMT, Raffaello Giulietti wrote: > Add useful constants specified in IEEE 754. This pull request has now been integrated. Changeset: fb605944 Author: Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e Stats: 52 lines in 2 files changed: 32 ins; 14 del; 6 mod 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double Reviewed-by: darcy - PR: https://git.openjdk.java.net/jdk/pull/8362
Re: RFR: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double [v2]
On Fri, 22 Apr 2022 16:34:46 GMT, Joe Darcy wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
>
> src/java.base/share/classes/java/lang/Double.java line 231:
>
>> 229: * @since 1.6
>> 230: */
>> 231: public static final int MAX_EXPONENT = (1 << (SIZE - PRECISION -
>> 1)) - 1;
>
> Please include the expected value as a comment; e.g.
>
> (1 << (SIZE - PRECISION - 1)) - 1; // 1023
Ready
> src/java.base/share/classes/java/lang/Float.java line 128:
>
>> 126: * The number of bits in the significand of a {@code float} value.
>> 127: * This is the parameter N in section {@jls 4.2.3} of
>> 128: * The Java Language Specification.
>
> Please use "cite" rather than "em" tags for references to the JLS.
Ready
-
PR: https://git.openjdk.java.net/jdk/pull/8362
Re: RFR: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double [v3]
> Add useful constants specified in IEEE 754. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double - Changes: - all: https://git.openjdk.java.net/jdk/pull/8362/files - new: https://git.openjdk.java.net/jdk/pull/8362/files/80a6fe2e..b4c1b61b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8362=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8362=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362 PR: https://git.openjdk.java.net/jdk/pull/8362
Re: RFR: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double [v2]
> Add useful constants specified in IEEE 754. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double - Changes: - all: https://git.openjdk.java.net/jdk/pull/8362/files - new: https://git.openjdk.java.net/jdk/pull/8362/files/830faf2b..80a6fe2e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8362=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8362=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362 PR: https://git.openjdk.java.net/jdk/pull/8362
Re: RFR: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
On Fri, 22 Apr 2022 14:26:07 GMT, Raffaello Giulietti wrote: > Add useful constants specified in IEEE 754. The precision of float resp. double values, as defined by IEEE 754, is not easily derivable from the constants in the java.lang.Float resp. java.lang.Double classes. These values (24 resp. 53) are used in some places in the OpenJDK code base, where they appear as literals or even as derived literals, like 23 and 52. Hence, usages of these values are harder to find than necessary. - PR: https://git.openjdk.java.net/jdk/pull/8362
RFR: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
Add useful constants specified in IEEE 754. - Commit messages: - 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double Changes: https://git.openjdk.java.net/jdk/pull/8362/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8362=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285477 Stats: 50 lines in 2 files changed: 32 ins; 14 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8362/head:pull/8362 PR: https://git.openjdk.java.net/jdk/pull/8362
RFR: 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false]
Please review these small changes to address intermittent failures, as of JDK-8274517. - Usage of jdk.test.lib.RandomFactory for reproducible random generation. - Slightly less restrictive assertion about badParallelStreamError on L94 (former L88). - Verbatim copy of computeFinalSum() from j.u.s.Collectors 18. While these changes do not necessarily guarantee absence of intermittent failures, the usage of jdk.test.lib.RandomFactory should at least help to pin down specific double sequences that do not pass the test. There is still an inherent variability due to the use of parallel streams, though. As double addition is not perfectly associative, even a fully known sequence of doubles may lead to slightly different results with parallelization. - Commit messages: - 8274517: java/util/DoubleStreamSums/CompensatedSums.java fails with expected [true] but found [false] Changes: https://git.openjdk.java.net/jdk/pull/8290/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8290=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274517 Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/8290.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8290/head:pull/8290 PR: https://git.openjdk.java.net/jdk/pull/8290
Integrated: 8284866: Add test to JDK-8273056
On Thu, 14 Apr 2022 11:31:03 GMT, Raffaello Giulietti wrote: > Hello, > this is a followup of JDK-8273056 to add a test to check that > Random.nextExponential() produces non-negative results. This pull request has now been integrated. Changeset: 3ffec3a5 Author:Raffaello Giulietti Committer: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/3ffec3a50b70051eba3fc7cd816e49811870f5d4 Stats: 58 lines in 1 file changed: 58 ins; 0 del; 0 mod 8284866: Add test to JDK-8273056 Reviewed-by: jlaskey - PR: https://git.openjdk.java.net/jdk/pull/8243
Re: RFR: 8284866: Add test to JDK-8273056 [v2]
> Hello, > this is a followup of JDK-8273056 to add a test to check that > Random.nextExponential() produces non-negative results. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8284866: Add test to JDK-8273056 Added copyright notice. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8243/files - new: https://git.openjdk.java.net/jdk/pull/8243/files/7ef3969d..792b5bab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8243=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8243=00-01 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8243.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8243/head:pull/8243 PR: https://git.openjdk.java.net/jdk/pull/8243
RFR: 8284866: Add test to JDK-8273056
Hello, this is a followup of JDK-8273056 to add a test to check that Random.nextExponential() produces non-negative results. - Commit messages: - 8284866: Add test to JDK-8273056 Changes: https://git.openjdk.java.net/jdk/pull/8243/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8243=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284866 Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8243.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8243/head:pull/8243 PR: https://git.openjdk.java.net/jdk/pull/8243
Integrated: 8283083: java.util.random L128X256MixRandom constructor fails to use byte[] seed
On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti wrote: > Please review this tiny fix. > > A test similar to the code proposed by the bug reporter has been added for > the LXM group. It does not pass before the fix and passes after. This pull request has now been integrated. Changeset: 19b140a7 Author: Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/19b140a7f30ea600d66bcf8370d94f5d6bf6d0d1 Stats: 60 lines in 2 files changed: 51 ins; 0 del; 9 mod 8283083: java.util.random L128X256MixRandom constructor fails to use byte[] seed Reviewed-by: jlaskey, bpb - PR: https://git.openjdk.java.net/jdk/pull/8207
Re: RFR: 8283083: java.util.random L128X256MixRandom constructor fails to use byte[] seed
On Tue, 12 Apr 2022 15:37:19 GMT, Raffaello Giulietti wrote: > Please review this tiny fix. > > A test similar to the code proposed by the bug reporter has been added for > the LXM group. It does not pass before the fix and passes after. j.u.Random and j.u.SplittableRandom do _not_ expose (byte[]) ctors. It's the factory that falls back to the () ctor if needed. A more sophisticated test could perhaps use reflection to discover which ctors are exposed. - PR: https://git.openjdk.java.net/jdk/pull/8207
