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.
Not all random generators ex
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.
-
Commit messages:
- 8283083: java.util.random L128X256MixRandom constructor fails to use byte[]
seed
Changes:
On Tue, 8 Feb 2022 22:11:34 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 t
it in another way, my understanding is, when the class gets loaded, it is
verified which doesn't necessarily lead to initialization, am I correct?
Best Regards
Cheng
-Original Message-
From: core-libs-dev On Behalf Of
Raffaello Giulietti
Sent: March 17, 2022 8:35 PM
To: core-libs-dev
der.
Could you explain a little more about why it goes in this way?
Best Regards
Cheng
-Original Message-
From: core-libs-dev On Behalf Of David
Holmes
Sent: March 17, 2022 7:46 PM
To: Raffaello Giulietti ;
core-libs-dev@openjdk.java.net
Subject: [EXTERNAL] Re: When to initialize the metho
int value) { return (value + 1); }
}
On 2022-03-17 20:38, Raffaello Giulietti wrote:
Hi,
as far as I can see, the code should not even compile, as there's a
static field in Test_1 which is initialized with an expression that
throws checked exceptions (findStatic(..)).
In addition, it seems to m
Hi Cheng,
I'm not sure I understand your point. By class initialization I mean
what's specified in the JVMS [1].
Are you concerned with initialization or with verification (which
precedes initialization)?
Raffaello
[1]
; }
}
On 2022-03-17 20:38, Raffaello Giulietti wrote:
Hi,
as far as I can see, the code should not even compile, as there's a
static field in Test_1 which is initialized with an expression that
throws checked exceptions (findStatic(..)).
In addition, it seems to me that there's nothing in y
Hi,
as far as I can see, the code should not even compile, as there's a
static field in Test_1 which is initialized with an expression that
throws checked exceptions (findStatic(..)).
In addition, it seems to me that there's nothing in your code that
reveals whether Test_2 has been
Hi,
specifying a fixed hashCode() algorithm has the important drawback that
it prevents evolution.
For example, as you note, String has a strictly specified algorithm [1]
that was perhaps a good one in the early days of Java (around 1995) but
has shown its deficiencies over the years. In
"Computer scientists of the world, unite!
Let's get rid of binary floating-point arithmetic in Java, after 27
years of honorable service!
Let's adopt decimal floating-point arithmetic, where 1 / 3 + 1 / 3 is
still different from 2 / 3, but who cares? At least we have 0.1 * 0.1 =
0.01, as
l << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D"
<< endl << endl;
cout << "0.1D*0.1D : ";
cout.precision(30);
cout << c << endl;
cout << "0.01D : ";
cout.precision(30);
The new decimal literals have indeed the minimal length required to
recover the doubles closest to the true mathematical values.
Raffaello
On 3/15/22 02:43, Joe Darcy wrote:
Depending on the range of the number line, a double value has between 15 and 17
digits of decimal precision. The
Hi,
Java, as well as most implementations of most languages, including C and
C++, have adopted the IEEE 754 floating-point standard, first issued in
1985. The standard specifies the formats, the outcome of operators and
comparisons up to the last bit.
Try out this C/C++ code (I'm on Linux
Right, and PI with 16 digits (or 17).
On 3/14/22 22:51, Hans Boehm wrote:
Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact
that this is actually a guaranteed floating point equality aids clarity.
On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti
Hello,
I find it a bit disturbing that PI is specified with 21 digits whereas
TAU has 16.
I think that specifying PI as
public static final double PI = 3.141592653589793;
doesn't harm anybody and makes it visually more consistent with TAU-
Greetings
Raffaello
On 3/14/22 22:13, Brian
On Tue, 8 Feb 2022 22:11:34 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 t
Hi Terry,
as pointed out by Martin, the real issue is using *binary*
floating-point arithmetic, like float or double, to emulate *decimal*
arithmetic.
When you write 0.1D in Java, C or C++, what happens is that this decimal
number is rounded to the double closest to the mathematical value
Hi,
on Windows, the mechanism to launch a new program is for the parent to
call CreateProcess(). This function accepts, among others parameters, a
lpApplicationName string and a lpCommandLine string. There's a *single*
lpCommandLine that encodes all the arguments to pass to the new program.
Hi,
as far as I know, on Windows every program can obtain the lpCommandLine
argument, used in the call of CreateProcess() from its parent, by
calling GetCommandLine() and parse that string as it sees fit. This is
in stark contrast with how Unix-like systems create and execute
programs, where
Hello,
to overcome some of the problems with parsing and generating Windows
command lines, I implemented two classes [1] that attempt to provide a
more sophisticated solution. To be clear, they do not create processes
or launch programs. They only serve as a parser and an "escaper".
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 12 commi
On Tue, 8 Feb 2022 20:18:22 GMT, Brian Burkhalter wrote:
>> The work (the code) has been published here on GitHub, so afaik the
>> copyright year cannot be simply changed without modifying something (beside
>> the year itself, which would be self-justifying)
>
> @rgiulietti You are correct: no
On Mon, 15 Nov 2021 19:31:09 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 t
On Tue, 8 Feb 2022 19:47:25 GMT, Brian Burkhalter wrote:
>> @bplb The last commit was pushed on Nov 15.
>> I guess I would have to merge against the latest master because of
>> test/langtools/tools/javac/sym/ElementStructureTest.java
>> and the intervening switch from JDK18 to JDK19.
>
>
On Tue, 8 Feb 2022 19:23:54 GMT, Brian Burkhalter wrote:
>> En attendant go! go!
>
> @rgiulietti Should we expect any more commits from you in this PR? Thanks.
@bplb The last commit was pushed on Nov 15.
I guess I would have to merge against the latest master because of
Hello,
I don't get why the author of myMethod() would/should be interested in
forcing the caller of the method to declare the variable b to be final.
Stated otherwise, what is the problem addressed by this suggestion?
Have you some specific case in mind?
Greetings
Raffaello
On 2022-02-02
separators and will split arguments.
For example, an argument with a semi-colon or comma, (unquoted) will be
split into two arguments when parsed by cmd.exe.
The goal is to improve the integrity and robustness of the command
encoding.
Thanks, Roger
On 1/28/22 4:07 AM, Raffaello Giuliett
Hello,
if I understand correctly, the issue addressed here (on Windows) is how
to assemble a single command string from an array of argument strings to
pass to CreateProcess() in a way that the individual argument strings
can be fully recovered in the invoked program.
Similarly when the
On Mon, 15 Nov 2021 19:31:09 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 t
Hello,
the simple answer is that
new String(...) == new String(...)
*never* evaluates to true )it might throw, though), whatever
constructors you are using and whatever arguments you pass to to them.
Some garbage collectors *might* de-duplicate the underlying arrays (but
you cannot
Hi,
if I understand correctly, you are supposing that method changeAmount()
is part of a security sensitive application under attack.
Its implementation first attempts a data validation by invoking
isUserIdAllowedOrThrowException(), then transforms validated data in a
lossy way (narrowing,
Hi Suminda,
please read my reply to you from May
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077081.html
Greetings
Raffaello
On 2021-11-17 14:54, Suminda Sirinath Salpitikorala Dharmasena wrote:
On Mon, 15 Nov 2021 19:31:09 GMT, Raffaello Giulietti
wrote:
Hello
Hello,
as mentioned in [1], the Schubfach writing accompanying JBS issues [2]
and [3] has recently undergone a thorough review by renowned researchers
(in addition to Dmitry Nadezhin back in 2018-19 and myself on a
continuous basis) [4].
For the *code* reviewers of PR [5] this means that
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: Dou
[4] https://labs.oracle.com/pls/apex/f?p=labs%3Abio%3A0%3A120
[5] https://members.loria.fr/PZimmermann/
[6] https://perso.ens-lyon.fr/jean-michel.muller/
[7] https://drive.google.com/file/d/1IEeATSVnEE6TkrHlCYNY2GjaraBjOT4f
[8] https://github.com/openjdk/jdk/pull/3402
On 2021-10-26 21:28, Raffaello Giuli
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 ten commi
Hello,
PR [1] and the accompanying article [2] have been subject to some
positive reactions in the last couple of weeks. A fresh set of about 20
thousand additional hard test cases kindly provided by Paul Zimmermann
of INRIA and other tests proposed by Guy Steele have been added to the code.
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 seve
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Fri, 16 Apr 2021 11:30:32 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 t
On Wed, 1 Sep 2021 20:13:38 GMT, Raffaello Giulietti
wrote:
> This PR ideally continues #5285, which has been closed as a consequence of
> inadvertently removing the branch on my repo. See there for initial
> discussion.
>
> Sorry for the mess.
This pull request has now
On Thu, 9 Sep 2021 23:44:49 GMT, Brian Burkhalter wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
>
> sr
> This PR ideally continues #5285, which has been closed as a consequence of
> inadvertently removing the branch on my repo. See there for initial
> discussion.
>
> Sorry for the mess.
Raffaello Giulietti has updated the pull request incrementally with one
additional commit
On Fri, 16 Apr 2021 11:30:32 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 t
On 2021-09-07 13:48, Stefan Zobel wrote:
On this blog entry (year 2017), Lemire is not giving any technical or
scientific argument in favor or against PCG.
He also refers to, and quotes from, a blog entry (year 2015) of an
influential researcher (whose work he respects) suggesting the entry
Hello,
On 2021-09-05 16:43, Andrew Haley wrote:
On 9/3/21 12:35 AM, John Rose wrote:
The reference I’d like to give here is to Dr. Melissa O’Neill’s
website and articles:
I'm quite sceptical. Anyone who says a (non-cryptographic) random-
number generator is "hard to predict" is either
This PR ideally continues #5285, which has been closed as a consequence of
inadvertently removing the branch on my repo. See there for initial discussion.
Sorry for the mess.
-
Commit messages:
- 8271602: Add Math.ceilDiv() family parallel to Math.floorDiv() family
Changes:
On Fri, 27 Aug 2021 18:53:23 GMT, Raffaello Giulietti
wrote:
> Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()`
> methods do `j.l.[Strict]Math`.
>
> Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this
> PR also corre
On Mon, 30 Aug 2021 22:25:09 GMT, Brian Burkhalter wrote:
>> Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()`
>> methods do `j.l.[Strict]Math`.
>>
>> Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`,
>> this PR also corrects small typos in it
On Fri, 27 Aug 2021 20:02:48 GMT, Raffaello Giulietti
wrote:
> This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`.
This pull request has now been integrated.
Changeset: 51167846
Author: Raffaello Giulietti
Committer: Brian Burkhalter
URL:
ht
This PR corrects a typo in the JavaDoc of `[Strict]Math.floorDiv(long,int)`.
-
Commit messages:
- 8273091: Doc of [Strict]Math.floorDiv(long,int) erroneously documents int in
@return tag
Changes: https://git.openjdk.java.net/jdk/pull/5287/files
Webrev:
Please review this PR to add officially endorsed `ceilDiv()` and `ceilMod()`
methods do `j.l.[Strict]Math`.
Beside adding fresh tests to `test/jdk/java/lang/Math/DivModTests.java`, this
PR also corrects small typos in it and exercises tests that were already
present but which were never
On Mon, 2 Aug 2021 19:59:57 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> please review this tiny change in the implementation of
> j.l.Math.floorMod(int, int).
>
> While the results are unaffected, all of
> floorDiv(int, int)
> floorDiv(long, long)
> f
On Mon, 2 Aug 2021 22:34:58 GMT, Raffaello Giulietti
wrote:
> Hello,
>
> please review the changes in documentation of floorDiv() and floorMod() in
> all their variants. Some are clarifications, some are corrections.
>
> Here's an example of a confusing formulation
On Wed, 4 Aug 2021 00:57:16 GMT, Brian Burkhalter wrote:
>> Raffaello Giulietti has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8271599: Javadoc of floorDiv() and floorMod() families is inaccurate in
&
;
>
> That's a questionable advice, as the sum in parentheses can lead to
> irrecoverable overflow (beside requiring two divisions instead of one).
> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the
> quite incorrect result -3, which is not even pos
;
>
> That's a questionable advice, as the sum in parentheses can lead to
> irrecoverable overflow (beside requiring two divisions instead of one).
> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the
> quite incorrect result -3, which is not even pos
;
>
> That's a questionable advice, as the sum in parentheses can lead to
> irrecoverable overflow (beside requiring two divisions instead of one).
> E.g., setting x = Integer.MAX_VALUE - 1, y = Integer.MAX_VALUE leads to the
> quite incorrect result -3, which is not even pos
On Thu, 29 Jul 2021 23:28:07 GMT, Brian Burkhalter wrote:
>> Add methods `floorDivExact(int,int)` and `floorDivExact(long,long)` to
>> `java.lang.Math` and `java.lang.StrictMath`.
>
> The `floorDivExact()` methods are identical to their `floorDiv()`
> counterparts aside from that they throw an
Hello,
please review the changes in documentation of floorDiv() and floorMod() in all
their variants. Some are clarifications, some are corrections.
Here's an example of a confusing formulation in the current doc
> "the / operator returns the integer closest to zero"
Literally, the integer
Hello,
please review this tiny change in the implementation of j.l.Math.floorMod(int,
int).
While the results are unaffected, all of
floorDiv(int, int)
floorDiv(long, long)
floorMod(long, long)
use x ^ y in the tests to correct the result if needed.
Not only is the proposed change
On Fri, 16 Apr 2021 11:30:32 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 t
Mysteries of JIT compilation...
On 2021-07-14 21:53, Brian Burkhalter wrote:
On Tue, 13 Jul 2021 17:21:52 GMT, Brian Burkhalter wrote:
Please consider this proposal to add `divideExact()` methods for integral data types to
`java.lang.Math` thereby rounding out "exact" support to all four
Sorry, typo
int q = x / y;
if ((x & y & q) >= 0) {
return q; // q, not r
}
throw new ArithmeticException("integer overflow");
On 2021-07-14 21:26, Raffaello Giulietti wrote:
One could also divide first and then check the result:
int q = x / y;
if ((x & y &
One could also divide first and then check the result:
int q = x / y;
if ((x & y & q) >= 0) {
return r;
}
throw new ArithmeticException("integer overflow");
No idea about relative perf.
On 2021-07-13 19:32, Brian Burkhalter wrote:
Please consider this proposal to add `divideExact()`
FWIW, adinn's branchless code together with
PR https://git.openjdk.java.net/jdk/pull/4660
make both methods less vulnerable to timing attacks.
Greetings
Raffaello
On 2021-07-02 15:50, Andrew Haley wrote:
On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn wrote:
You can also do that branchlessly
... or even as a one liner, like in the test
return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >>
(Long.SIZE - 1)) & x);
On 2021-07-02 13:08, Andrew Dinn wrote:
On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley wrote:
src/java.base/share/classes/java/lang/Math.java line
to clear the soft reference objects when OOME is thrown as
specified even the object allocation request is known to fail.
Mandy
On 6/3/21 11:57 AM, Raffaello Giulietti wrote:
Hi,
upon reading [1] I tried a similar scenario, but where OOME are caused
by "Java heap space&qu
Hi,
upon reading [1] I tried a similar scenario, but where OOME are caused
by "Java heap space" exhaustion rather than by VM limits.
import java.lang.ref.SoftReference;
import java.text.DecimalFormat;
import java.util.ArrayList;
public class Softly {
public static void main(String[]
On Tue, 1 Jun 2021 19:51:39 GMT, Raffaello Giulietti
wrote:
> Trivial changes to this non-normative document.
This pull request has now been integrated.
Changeset: 5405f983
Author: Raffaello Giulietti
Committer: Stuart Marks
URL:
https://git.openjdk.java.net/jdk/com
Trivial changes to this non-normative document.
-
Commit messages:
- 8268077: java.util.List missing from Collections Framework Overview
Changes: https://git.openjdk.java.net/jdk/pull/4289/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4289=00
Issue:
Hi,
can anybody take a look at this?
I would do it myself but I don't have Author status to add an issue to
the JBS.
Should be a trivial change.
Thanks
Raffaello
On 2021-05-30 18:03, Raffaello Giulietti wrote:
Hello,
seems like java.util.List is missing from the list in the "Colle
Hello,
seems like java.util.List is missing from the list in the "Collection
Interfaces" section in
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/doc-files/coll-overview.html
Should be easy to fix and doesn't seem to require a CSR as the document
is non-normative.
On Fri, 16 Apr 2021 11:30:32 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 t
Hi,
a reminder to keep PR [1] alive and to invite interested reviewers to
comment it.
The corresponding CSR is in [2]
Greetings
Raffaello
---
[1] https://github.com/openjdk/jdk/pull/3402
[2] https://bugs.openjdk.java.net/browse/JDK-8202555
Hi Alberto,
there's an understandable tendency to wish to add convenience/utility
methods like the ones you are proposing. Often, however, the perceived
benefits are not assessed accurately. In other words, convenience
methods in core libraries must be of real general interest.
Coming to
most welcome.
Suminda
On Fri, 5 Feb 2021 at 21:51, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>> wrote:
Hello,
as a reminder, a Java implementation of Schubfach [1] intended to
replace the current slow and expensive OpenJDK
(Doubl
On Wed, 7 Apr 2021 18:49:36 GMT, Raffaello Giulietti
wrote:
> (Changed to new branch in personal fork)
>
> Please review these small tweaks.
> For background information see
> [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
>
>
on GitHub :-)
Greetings
Raffaello
On 2021-04-18 23:19, Andrey Turbanov wrote:
On Fri, 16 Apr 2021 11:30:32 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
trivial and potentially could benefits to jdk itself to reduce
memory garbage : is Integer.toString(int) widely used in the jdk codebase ?
Finally it can be alternatively implemented in application's code.
My 2 cents,
Laurent
Le sam. 17 avr. 2021 à 11:06, Raffaello Giulietti
On 2021-04-17 07:07, David Holmes wrote:
On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
I guess the reporter meant to limit the cache range similarly to the
one used for valueOf().
I have no clue about the benefit/cost ratio for the proposed String
cache. It really depends on usage
?
And what technique can be applied to limit the size of the cache.
The size of the small integer cache is somewhat arbitrary.
Regards, Roger
On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
Hello,
does the enhancement proposed in [1] make sense, both today and when
wrappers will be migrated
Hello,
does the enhancement proposed in [1] make sense, both today and when
wrappers will be migrated to primitive classes?
If so, it should be rather simple to add it and I could prepare a PR.
If not, the issue might perhaps be closed.
Greetings
Raffaello
[1]
Hello,
the reporter of [1] seems to understand that the current behavior is
well specified (since ever) and correctly implemented. Also, it's
unclear how s/he would like to enhance it.
Shouldn't [1] be closed?
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8246334
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: Dou
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 c
On Fri, 16 Apr 2021 08:22:41 GMT, Jan Lahoda 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
>>
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 c
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 c
101 - 200 of 342 matches
Mail list logo
