Hi Kengo,
I don't think this is a bug, as records are designed to "act as
transparent carriers for immutable data". A record having an array-typed
component is far from being immutable because everyone can change the
array contents. So you probably shouldn't opt for records for such use
Hello,
I'm just curious about the status of the important project described by
"JEP draft: Predictable regex performance" [1].
Afaiu, there are mentions about:
* Using the native re2 library [2] via JNI, with the cons that usage
becomes kind of unnatural, like "closing" the pattern to
igned with Math.sqrt(x) in Java.
We already allow some plausible behaviors to be different with the IEEE
recommendations for some special cases, right?
And in that case, we can replace pow(x, 0.5) with sqrt(x) safely.
Thanks.
Best regards,
Jie
On 2021/4/12, 6:40 PM, "Raffaello Giuliet
Hi Jie,
the behavior you report is the one specified by the standard IEEE 754.
Java follows this standard as closely as it can.
The standard says that
* squareRoot(-0) = -0
* squareRoot(-∞) = NaN
Also, the standard has a long lists of special cases for pow(x, y),
among them:
* pow(±0, y)
On Fri, 9 Apr 2021 16:44:18 GMT, Raffaello Giulietti
wrote:
>> @rgiulietti Please issue the `/csr/` command here [1]. Speaking of which,
>> does the CSR [2] need to be updated?
>>
>> [1]
>> https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#
On Fri, 9 Apr 2021 16:39:45 GMT, Brian Burkhalter wrote:
>> Hello,
>>
>> here's some background information for those that didn't follow the mailing
>> list for the last couple of years.
>>
>> Some enjoyable properties of the novel algorithm:
>> * No intermediate objects are instantiated.
>>
On Thu, 8 Apr 2021 21:20: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
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
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
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)
>
>
(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)
Greetings
Raffaello
-
Commit messages:
- 8264514: HexFormat implementation tweaks
Changes:
On Wed, 31 Mar 2021 21:39:46 GMT, Raffaello Giulietti
wrote:
> Please review these small tweaks.
>
> For background information see
> [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
>
> Greetings
> Raffaello
This pull request has been
> Please review these small tweaks.
>
> For background information see
> [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
>
> Greetings
> Raffaello
Raffaello Giulietti has refreshed the contents of this pull request, and
previous comm
, so I need to check
that nothing has changed in the meantime.
I'll prepare a PR in the next couple of days.
On 2021-04-07 00:44, Brian Burkhalter wrote:
On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>
wrote:
if there's revived interest I
M, Andrew Haley mailto:aph at
redhat.com><mailto:aph at redhat.com>> wrote:
On 4/5/21 9:08 AM, Alan Bateman wrote:
On 04/04/2021 09:53, Andrew Haley wrote:
:
We also have a candidate for a String -> toDouble parser from Raffaello
Giulietti:
https://mail.openjdk.java.net/pipermail/
prices, extensions, taxes, discounts, totals, etc.
On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti
wrote:
Hi Douglas,
yes, different vendors have different limits on the precision, the most extreme
probably being PostgreSQL.
But apart from that, the arithmetic is different.
A better
Please review these small tweaks.
For background information see
[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)
Greetings
Raffaello
-
Commit messages:
- 8264514: HexFormat implementation tweaks
Changes:
support huge numbers exactly. Instead they find workarounds that are more
efficient. Decimal128 would be a substantial improvement for those apps.
Douglas
On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti
wrote:
Hi,
I think there's a misunderstanding about the nature of IEEE 754 Decimal
(e.g
Ciao Maurizio,
admittedly, yours is a fairly convincing argument to wait for the
completion of Valhalla, or at least JEP 401.
Personally, I wouldn't mind having to denote the primitive class as
Decimal128.val in some future (2022? 2023? who knows?) if I could use
Decimal128 tomorrow, but I
Hi,
I think there's a misunderstanding about the nature of IEEE 754
Decimal (e.g., Decimal64), the subject of this thread, and the nature
of SQL DECIMAL(p, s).
SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an
overall maximum precision p and a scale s, the number of digits
Hello Roger,
these are the changes I'm proposing after reviewing the code of
j.u.HexFormat. The modified code available here
https://github.com/rgiulietti/jdk/commit/6759a25eb952ab19a045a83349d41b82cc1b07cb
In addition to other smaller, hopefully self-explanatory enhancements,
here are the
Ciao Maurizio,
thanks for your interest.
On 2021-03-30 23:01, Maurizio Cimadamore wrote:
Add me to the list of interested folks.
Will do.
Such types are useful when interacting with System ABIs, and the Foreign
Linker API needs "well-known" carrier which model these types in Java.
Hi Paul,
On 2021-03-30 22:54, Paul Sandoz wrote:
On Mar 30, 2021, at 1:03 PM, Brian Goetz wrote:
Overall, I'd be happy to see Decimal types that are aimed at "reasonable
precision" in addition to the infinite precision that BD offers. (After Valhalla,
of course.)
Yes, me too.
s. (After
Valhalla, of course.)
On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
Hello,
I'm experimenting with an implementation of Decimal64 and Decimal128,
two standard IEEE 754-2019 formats supporting, well, decimal floating
point numbers of up to 16 resp 34 decimal digits.
Hi Joe,
On 2021-03-30 21:56, Joe Darcy wrote:
Hi Raffaello,
On 3/29/2021 1:14 PM, Raffaello Giulietti wrote:
Hello,
Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal
type should be usable for testing at least. For in-range values not near
the exponent range, the
Raffaello
This would be interesting to have.
It would be better if the full set of numbers b16-256 and d32-128 are
implemented so there is full coverage of all IEEE 754 numbers.
On Tue, 30 Mar 2021 at 01:45, Raffaello Giulietti <
raffaello.giulietti at gmail.com> wrote:
Hello
access).
Greetings
Raffaello
On 2021-03-26 16:08, Roger Riggs wrote:
fyi, a PR to make the methods static.
https://git.openjdk.java.net/jdk/pull/3205
On 3/15/21 4:26 PM, Raffaello Giulietti wrote:
Hello,
I understand your points expressed in
https://mail.openjdk.java.net/pipermail/core
Hello,
I'm experimenting with an implementation of Decimal64 and Decimal128,
two standard IEEE 754-2019 formats supporting, well, decimal floating
point numbers of up to 16 resp 34 decimal digits.
While BigDecimal can simulate most finite number computations on these
formats by passing
of consistency vs another.
I was/am looking for additional comments to weigh one or the other
alternative.
I did receive one offline comment in support of static methods on the
rationale of
convenience.
Regards, Roger
On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
Hi,
the javadoc of most
hods below is, for example,
HexFormat.of().isHexDigit('F')
(because there are almost no additional costs wrt static methods.)
But I don't see a reason why they should be non-static. Just oversight?
Greetings
Raffaello
On 2021-03-08 11:52, Raffaello Giulietti wrote:
Hello,
it appears that all of the
Hello,
it appears that all of the following API methods in [1] can be declared
*static*, which makes them more useful in contexts where there's no
instance of HexFormat available or none is desired.
As 17 has not yet entered any formal phase, the change should be harmless.
public boolean
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8259896
[2]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-February/074407.html
Hello Raffaello,
I have added this comment from you, to that JDK-8259896 issue.
-Jaikiran
On 02/02/21 12:43 am, Raffaello Giulietti wrote
Hello,
as a reminder, a Java implementation of Schubfach [1] intended to
replace the current slow and expensive OpenJDK (Double|Float)::toString
algorithm has been discussed, presented and contributed to this mailing
list in several posts. The last implementation is available in pre-Skara
Hello Joe,
in the javadoc of acos() I think you should replace the mathematically
incorrect
* If the argument is {@linkplain Double#isInfinite infinite},
with something like
* If the argument is zero,
Also, in some places pi/2 is described as
pi/2, rounded,
which is more open to
Hi,
in my opinion, the reporter of [1] is right in requiring that extraneous
characters be discarded, even inside the padding.
Indeed, the first full paragraph on [2] reads:
"Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data."
where "the base64 alphabet"
Hi,
in my opinion, and contrary to the report [1], the described issue is
not a bug.
While the wording used in the spec of java.math.RoundingMode could be
improved, it is nonetheless clear enough to avoid any confusion about
what HALF_DOWN and HALF_UP mean in this context. The actual values
On Sun, 6 Sep 2020 15:25:10 GMT, Raffaello Giulietti
wrote:
> This is a follow-up of the Mercurial-based workflow initiated on the
> core-lib-devs mailing list [0]. Not sure if this one is strictly necessary or
> if the patches sent on the list are sufficient. Anyway, I exploi
On Sat, 17 Oct 2020 00:16:57 GMT, Brian Burkhalter wrote:
>> Hello,
>>
>> a reminder that this issue has not been formally reviewed.
>> Estimated time: 10-15 min with "Hacker's delight" on the desk.
>>
>> Greetings
>> Raffaello
>
> I think the change looks good.
>
> Before the project was on
net/pipermail/core-libs-dev/2020-September/068474.html
Raffaello Giulietti has updated the pull request incrementally with one
additional commit since the last revision:
Modified copyright year.
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/31/files
- new: https://gi
On Thu, 24 Sep 2020 15:33:01 GMT, Raffaello Giulietti
wrote:
>> @shipilev I agree, but that's the title chosen by the reporter of the JBS
>> issue. Not sure I can edit it without
>> impacting bots and tools.
>
> Hello
>
> this is a gentle reminder that this i
On Wed, 9 Sep 2020 07:38:38 GMT, Raffaello Giulietti
wrote:
>> Since this patch does not involve adding the intrinsic, maybe drop "(Needs
>> to be intrinsic)" from the synopsis?
>
> @shipilev I agree, but that's the title chosen by the reporter of the JBS
Hello,
FYI I just opened a PR on GitHub for this RFR.
Greetings
Raffaello
On 2020-09-03 00:44, Brian Burkhalter wrote:
Good move. ;-)
Brian
On Sep 2, 2020, at 2:26 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>
wrote:
will do in the next days, hopefully
Hi Roger,
In Formatter
(1) The javadoc reads: "Returns up to sixteen [...]" rather than
"Returns sixteen [...]", similar to the other toHex() methods.
(2) equals() and hashCode() are missing.
In Parser
(1) In methods fromHex(), isHex(), xxxFromHex(), you probably meant
"static" rather
Hi Joe,
I modified the values in method testDivideAndRemainder(), without
touching the logic.
The values are odd and even dividends and divisors around 0, 2^31, 2^32,
2^33, 2^63 and 2^64.
Is this OK?
Greetings
Raffaello
On 2020-09-02 23:26, Raffaello Giulietti wrote:
will do
d.
After these, I didn't care to measure remainderUnsigned(). It could be
done similarly.
Greetings
Raffaello
On 2020-09-02 23:26, Raffaello Giulietti wrote:
I'll also add JMH results.
if more cases should be added with the new algorithm.
Potentially, the existing algorithm could retire to serve as a reference
in the regression tests.
Thanks,
-Joe
On 9/2/2020 7:37 AM, Raffaello Giulietti wrote:
Hi Brian,
thanks for taking a look.
I didn't write JMH benchmarks.
Greetings
Hi Brian,
thanks for taking a look.
I didn't write JMH benchmarks.
Greetings
Raffaello
On 2020-09-02 16:25, Brian Burkhalter wrote:
Hi Raffaello,
I can take a look. Did you write any (JMH?) microbenchmarks?
Thanks,
Brian
On Sep 2, 2020, at 5:52 AM, Raffaello Giulietti
7ed30a79d31
# Parent 2fc1acf9c89458a1d05915963961d7c780cb6ad3
Patch to fix JDK-8238669
8238669: Long.divideUnsigned is extremely slow for certain values (Needs
to be Intrinsic)
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/lang/Long.java
b/src/jav
AM, Raffaello Giulietti wrote:
...
(3) The expressions preLen > origLen - sufLen on L.492 and sufLen >
origLen - preLen on L.496 are equivalent. The latter is thus useless on
L.496 because it is always false when execution reaches here.
true; updated to optimize the case of empty
In the meantime I'll nevertheless take a look at the current
implementation of the Decoder.
Greetings
Raffaello
Hi Roger,
here are my notes about the Decoder.
(1) The only serious issue I could find is on L.548. It should read
L.548 CharBuffer cb = CharBuffer.wrap(chars, index, index
Hi Roger,
On 2020-08-21 18:38, Roger Riggs wrote:
Hi Rafaello,
(It's Raffaello, with 2 effs.)
I'll let some of the higher level API questions settle before updating
the webrev.
Thanks, Roger
Sure.
In the meantime I'll nevertheless take a look at the current
implementation of the
Hi Roger,
I'm only a contributor, not an official reviewer. Despite this, I would
like to make some notes about the encoder part.
(1) Comparing with other APIs that accept a range of a byte[], my
understanding is that encode(byte[], int, int) should throw IOOE when
index < 0 or too big,
Hi Roger,
in the examples in the javadoc you might want to correct the first
argument to Hex.encoder and Hex.decoder to "," to be consistent with the
narrative.
Greetings
Raffaello
JavaDoc:
http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html
Hi,
if nobody else is already fixing JDK-8233760 [1], I would like to start
digging into it, as it still affects a recent changeset [2].
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8233760
[2] http://hg.openjdk.java.net/jdk/jdk/rev/78705826c520
Thanks Brian for pushing
On 2020-08-07 23:12, Brian Burkhalter wrote:
On Aug 7, 2020, at 9:39 AM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>> wrote:
There's one corner case that would not pass, however, so I added
testNegativeOffsetZeroLength() to exercise that. It passes on the
On Aug 6, 2020, at 2:36 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>
wrote:
the body of readFully() seems to silently assume that the other
arguments are correct (e.g., off >= 0 and so on).
In the (still) current implementation of
DataInputStream.readFully(by
ext
days if deemed necessary.
Greetings
Raffaello
On 2020-08-06 22:09, Brian Burkhalter wrote:
On Aug 6, 2020, at 12:36 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>
wrote:
This looks all right. I would be inclined to do like in [1] and throw
the RuntimeException on
# Parent b01985b4f88f554f97901e53e1ba314681dd9c19
Patch to fix JDK-8245036
8245036: DataInputStream.readFully(byte[], int, int) does not throw
expected IndexOutOfBoundsExceptions
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/io
adFully(byte[], int, int) does not throw
expected IndexOutOfBoundsExceptions
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/io/DataInputStream.java
b/src/java.base/share/classes/java/io/DataInputStream.java
--- a/src/java.base/share/classes/java
Hi,
a gentle reminder to review this almost trivial patch.
Greetings
Raffaello
On 2020-07-29 19:44, Raffaello Giulietti wrote:
Hi Tagir,
here's yesterday's patch with added unit tests.
Greetings
Raffaello
On 2020-07-29 05:26, Tagir Valeev wrote:
Hello!
Having a unit-test would
Hi Tagir,
here's yesterday's patch with added unit tests.
Greetings
Raffaello
On 2020-07-29 05:26, Tagir Valeev wrote:
Hello!
Having a unit-test would be nice!
With best regards,
Tagir Valeev.
On Tue, Jul 28, 2020 at 9:04 PM Raffaello Giulietti
wrote:
Hello,
here's a very simple
to fix JDK-8245036
8245036: DataInputStream.readFully(byte[], int, int) does not throw
expected IndexOutOfBoundsExceptions
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/io/DataInputStream.java
b/src/java.base/share/classes/java/io
also run the JCK tests in this area as well as mach5 tiers1-3
(which I believe Roger has also)
Best
Lance
On Jul 15, 2020, at 5:44 PM, Raffaello Giulietti
<mailto:raffaello.giulie...@gmail.com>> wrote:
Hi Roger,
On 2020-07-15 22:21, Roger Riggs wrote:
Hi Raffaello,
Base64.java:
2:
Hello,
the CSR for read(char[],int,int) does not explicitly specify that "line
terminators are compressed into single newline ('\n') characters", as
the no-arg read() spec does.
Thus, it's not entirely clear what happens when the buffer is just large
enough to accept the \r in a \r\n
27: Please add the bug number to the @bug line.
Style-wise, I would remove the blank lines at the beginning of blocks.
(1095, 1115)
Done.
Thanks, Roger
On 7/14/20 11:47 AM, Raffaello Giulietti wrote:
Hi Roger,
here's the latest version of the patch.
I did:
* Withdraw the si
# Node ID 2bebe2aced4c3fa3b42b3c6ee445f9b7b0d20b5d
# Parent a5649ebf94193770ca763391dd63807059d333b4
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/util/Base64.java
te about allowing limit to overflow to MIN_VALUE is informative
but it would
be better to avoid it and keep a future maintainer from falling into the
trap.
Regards, Roger
On 7/6/20 4:48 PM, Raffaello Giulietti wrote:
Hi Roger,
the structure of the original design is preserved, the details change
wi
uot; on continuation lines.
Regards, Roger
On 7/3/20 11:48 AM, Raffaello Giulietti wrote:
Hello,
after Roger's notes, which escaped my attention before, I've withdrawn
all the changes but for DecInputStream, *except* that I couldn't
resist to simplify the maths in encodedOutLength(), while
# Parent a7c0307232406c7b0c1a4b8c2de111077848203d
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/util/Base64.java
b/src/java.base/share/classes/java/util/Base64
2020 +0200
# Node ID 72f0e35ada03c4b850dc1bcd47e3296f14c6e531
# Parent a7c0307232406c7b0c1a4b8c2de111077848203d
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/util
Hello,
does anybody know what the progress of this JEP is?
How could I contribute?
Greetings
Raffaello
On 2020-06-24 19:22, Raffaello Giulietti wrote:
Hi,
seems like the last activity in JBS related to this JEP [1, 2] dates
back to June 2019.
Are there major stumbling blocks?
Can I
4a91f6b96a506d9d67437338c33b6953a57bfbd9
8222187: java.util.Base64.Decoder stream adds unexpected null bytes at
the end
Reviewed-by: TBD
Contributed-by: Raffaello Giulietti
diff --git a/src/java.base/share/classes/java/util/Base64.java
b/src/java.base/share/classes/java/util/Base64.java
--- a/src/java.base/share
Hello,
beside the usual request to this community to review the Schubfach
algorithm and its efficient implementation [1, 2], I'm pleased to
announce that they have been adopted resp. adapted as part of
jsoniter-scala [3, 4], a project aiming to be the fastest JSON
parsing/serialization
Hi,
seems like the last activity in JBS related to this JEP [1, 2] dates
back to June 2019.
Are there major stumbling blocks?
Can I contribute in any way?
Greetings
Raffaello
[1] http://openjdk.java.net/jeps/356
[2] https://bugs.openjdk.java.net/browse/JDK-8193209
on both the
library and
the callers.
Its worth creating a separate issue and looking at it separately.
Thanks, Roger
On 6/23/20 10:50 AM, Raffaello Giulietti wrote:
Hi Roger,
I didn't yet implement the strict check since, as you point out, it
could harm existing code in the wild, even
tests fail if the non-canonical encoding throws?
Thanks, Roger
On 6/23/20 9:00 AM, Raffaello Giulietti wrote:
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad
bits must be set to zero.
However, the current decoder implementation in java.util.Base64
a
Hi,
the InputStream.read(byte[], int, int) method [1] can throw
* IOException
* NullPointerException
* IndexOutOfBoundsException
Is there a recommended priority for the conditions associated to the
exceptions to be checked? For example, if the arguments are invalid and
the stream is already
Hi,
in defense of the current spec, integer arithmetic is signed by default
and unsigned behavior is evident from the method names, like
Long::compareUnsigned or Long::divideUnsigned
But your spec is even clearer ;-)
Greetings
Raffaello
In retrospect I don't know why I expected
Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad bits
must be set to zero.
However, the current decoder implementation in java.util.Base64 accepts
non-canonical encodings as well. For example, all of the following four
encodings
KCk=
KCl=
KCm=
KCn=
where only the
22:34, Lance Andersen wrote:
Hi Raffaello,
If you are interested in providing a fix, you are more than welcome to
do so. Please include a test which validates your fix.
Best
lance
On Jun 8, 2020, at 3:45 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>>
wrote:
Raf
Hello,
as of a very recent changeset [1], this bug [2] is still present.
While the bug already has an assignee, there seems to be no recent
activity, so I'd like to contribute fixing it.
Greetings
Raffaello
[1] http://hg.openjdk.java.net/jdk/jdk/rev/ac47db0c7ccb
[2]
9:24 AM, Raffaello Giulietti wrote:
Hi,
[1] enumerates 14 StrictMath native functions that still need a Java
porting from the original C code.
As of changeset b84f122ea855 all of them are still native, so I wonder
if it makes sense to contribute or if they have already been ported
Hi,
not sure if the lack of replies means that my previous post has been
overlooked?
Greetings
Raffaello
On 2020-05-25 18:24, Raffaello Giulietti wrote:
Hi,
[1] enumerates 14 StrictMath native functions that still need a Java
porting from the original C code.
As of changeset
Hi,
[1] enumerates 14 StrictMath native functions that still need a Java
porting from the original C code.
As of changeset b84f122ea855 all of them are still native, so I wonder
if it makes sense to contribute or if they have already been ported and
on the launch pad for integration.
Let
Hi,
afaik, review of [1] (webrev in [2]) didn't progress in the meantime.
I'm very well aware that a full review requires some time (see [3] for
my estimates), depending on your familiarity in working out the maths in
[4] (*no* numerics, *no* floating-point arithmetic, promised!).
Yet, the
in the cloud. Nevertheless, many trillions have been tested.
Greetings
Raffaello
On 2020-04-30 18:31, Raffaello Giulietti wrote:
> On 2020-04-30 15:29, Alan Bateman wrote:
>> On 30/04/2020 13:54, Raffaello Giulietti wrote:
>>> Hi,
>>>
>>> after more t
On 2020-04-30 15:29, Alan Bateman wrote:
On 30/04/2020 13:54, Raffaello Giulietti wrote:
Hi,
after more than one year after first publication, the patches [1] and
the CSR [2] are still awaiting a review...
Here's a breakdown of estimated times:
* Reading the CSR: 15-30 min. This can
Hi,
after more than one year after first publication, the patches [1] and
the CSR [2] are still awaiting a review...
Here's a breakdown of estimated times:
* Reading the CSR: 15-30 min. This can be done and approved independently.
* Checking that the implementation matches the documentation
Hi Mandy,
OK, I'll file a record in the JBS. Thanks for sponsoring
Raffaello
On 2020-04-24 18:17, Mandy Chung wrote:
Yes any change requires a JBS issue.
I can sponsor this trivial fix.
Mandy
On 4/24/20 5:15 AM, Raffaello Giulietti wrote:
Not sure if this requires an entry in the JBS
Not sure if this requires an entry in the JBS...
Greetings
Raffaello
diff -r 70c2239696ae
src/java.base/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
Fri Apr 24 16:12:53 2020 +0530
+++
Hi,
I'm on Linux, but the explanation might be the same as the following one.
An easier way to obtain the same error on OpenJDK8 + HotSpot is to execute
byte[] b = new byte[Integer.MAX_VALUE];
which is exactly what happens behind the scenes in the UTF-8 case.
The encoder pessimistically
Hello,
curious about Double.toString(double) performance?
Here are the results obtained by jmh 1.23 on a recent changeset [1]. The
benchmark is over the full range of bitwise uniformly distributed random
doubles.
# VM options:
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations,
Hello,
here's the periodic monthly reminder that the latest patches to overcome
[1] have been submitted [2] and are waiting for a review.
Full background documentation is available at [3].
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2]
No, the javadoc is identical, so there's no need to update the CSR.
R
On 2020-03-17 22:14, Brian Burkhalter wrote:
Raffaello,
Is there any change which would necessitate updating the CSR?
Thanks,
Brian
On Mar 17, 2020, at 2:13 PM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>>
Hello,
here's the periodic monthly reminder that the latest patches of [1] have
been submitted more than 10 months ago [2] and are waiting for a review.
Full background documentation is available at [3].
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2]
This is the usual, familiar monthly reminder that the latest patches of
[1] have been submitted more than 9 months ago [2] and still need a review.
Full background documentation is available at [3].
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2]
On 2019-12-27 22:16, Andrew Haley wrote:
> On 12/27/19 11:43 AM, Raffaello Giulietti wrote:
>> The latest patches of [1] have been submitted more than 8 months ago
[2].
>> I'm still looking for motivated reviewers.
>
> I am sorely aware that we have not performed well.
The latest patches of [1] have been submitted more than 8 months ago [2].
I'm still looking for motivated reviewers.
Greetings
Raffaello
[1] https://bugs.openjdk.java.net/browse/JDK-8202555
[2] http://cr.openjdk.java.net/~bpb/4511638/webrev.03/
.
Cheers
Maurizio
On 09/12/2019 10:11, Raffaello Giulietti wrote:
Hi,
will there be a
MemoryAddress.move(MemoryAddress src, MemoryAddress dst, long bytes)
method with POSIX memmove(3) semantics at some point?
That would be useful, e.g., to "open a hole" into an array by
shifting existin
2019 18:29, Raffaello Giulietti wrote:
Hello,
great job!
I think that the doc of MemoryAddress.copy() should be explicit about
the direction of the copying, so it should either:
Thanks! - I'll rectify the doc to specify lower-to-higher.
Maurizio
* explicitly specify a direction, e
201 - 300 of 342 matches
Mail list logo
