Re: Update to the Double::toString(double) Javadoc

Hi Joe, so I beg Brian to get in touch with me for the CSR review. I'm familiar with the paper of Steele and White. For background on the design of my contribution see [1]. Greetings Raffaello [1] https://9b7022c5f9.files.wordpress.com/2018/04/todec.pdf On 2018-04-27 20:58, joe darcy

Update to the Double::toString(double) Javadoc

Hi, as may be known, the current Javadoc for Double::toString(double) is not specific enough. As a consequence, different implementations can return different results. To see this, here are some quotes from the Javadoc. It asks: "How many digits must be printed for the fractional part of m or

speedup factors of the proposed re-implementation of Double.toString(double)

Hi, in order to elicit some concrete interest in the proposed re-implementation of Double.toString(double) [1] to overcome the known issues [2], I prepared a jar in [3] that runs some benchmarks comparing the execution times. It can be executed directly as: java --module-path todecbench.jar

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi, my code is now ready to be uploaded to the OpenJDK reps. Currently it resides on GitHub and is under the "GPLv2 + Classpath Exception" license, with myself as the copyright holder. I asked Oracle about how the copyright notice should be adapted to meet the OCA requirements but, as of

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Thanks Mark, in your position as the Chief Architect, Java Platform Group at Oracle, I take yours as the most authoritative answer I've got so far. Tomorrow I should find the time to finally upload the code. Thanks to everybody who kindly replied to this thread. Greetings Raffaello On

uploading of new code

Hi, in thread [1] I mention a clean room implementation of Double.toString(double) and my willingness to contribute it to the OpenJDK project to fix [2]. As of today, my code resides in a module that exports a package simply named "math". The reason I do not alter the original OpenJDK

Re: uploading of new code

On 2018-04-18 16:35, Aleksey Shipilev wrote: > On 04/18/2018 03:58 PM, Andrew Haley wrote: >> On 04/18/2018 02:55 PM, raffaello.giulie...@gmail.com wrote: >>> So, how can I best proceed with this initial delivery? >> >> Once you have an OpenJDK id you can get an account on cr.openjdk.java.net. >>

Re: uploading of new code

On 2018-04-18 19:42, mark.reinh...@oracle.com wrote: 2018/4/18 10:27:36 -0700, e...@zusammenkunft.net: Hello, I would put it on a standalone Git repo on one of the public hosting sites lile.Github, especially for a first discussion (especially good if added JMH comparisions). I would not expect

Upload of drop-in replacement for Double:::toString(double)

xception statement from your version. module-info.java /* * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it * under the terms of the

Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi, the topic I would like to work on is to solve the bugs described at https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4511638 about the results produced by the current implementation of Double::toString(double). I noticed that after all these years most of the issues illustrated in the bug

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

Hi Brian, On 2018-03-30 22:42, Brian Burkhalter wrote: > Hello Raffaello, > > On Mar 30, 2018, at 9:50 AM, raffaello.giulie...@gmail.com > wrote: > >> the topic I would like to work on is to solve the bugs described at >>

Re: Coding conventions for core-libs-dev

gt; <mailto:fo...@univ-mlv.fr>> wrote: > > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > is the closest you can find as an official coding convention for the > OpenJDK. > > Rémi > > - Mail original - > > De: "

Coding conventions for core-libs-dev

Hi, are there any Java coding conventions to follow? I found very outdated guidelines at http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html with ab archaic line limitation of 80 or even 70 chars/line. Are there official, semi-official or suggested documents?

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi, On 2018-10-02 20:17, Martin Buchholz wrote: > Raffaello and Ulf should talk. I work on this project in my spare time, which is limited and not entirely devoted to programming for the OpenJDK, of course ;-) Starting this weekend, I'll try to recollect my notes and organize them in paper or

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2018-10-03 11:12, Andrew Dinn wrote: > On 02/10/18 19:17, Martin Buchholz wrote: >> Raffaello and Ulf should talk. >> It seems like Ulf's ryu project is trying to solve the same problem. >> ryu is also still being worked on, but there is already a published paper >> and ryu is being adopted by

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2018-10-04 15:28, Ulf Adams wrote: > On Thu, Sep 27, 2018 at 5:37 PM Raffaello Giulietti > mailto:raffaello.giulie...@gmail.com>> > wrote: > > Hi Ulf, > > > On 2018-09-27 16:40, Ulf Adams wrote: > > Hi Raffaello, > > > > I

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi Brian, On 2018-09-27 01:53, Brian Burkhalter wrote: There was a compilation error on Linux in one of the tests: test/jdk/java/lang/Floating/DoubleToDecString.java:133: error: unmappable character (0x93) for encoding US-ASCII Paxson V, "A Program for Testing IEEE

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi Andrew, In principle I agree with you. However, in this case the maths underlying the algorithm to select the decimal are too involved to explain in comment form. I'm in the course of preparing a paper that explains the idea and the details. Then it should be easier to make sense out of

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi Andrew, On 2018-09-27 14:57, Andrew Dinn wrote: > On 27/09/18 13:23, Raffaello Giulietti wrote: > . . . >> The comments of the accessor methods that make use of this private table >> implicitly explain its semantics as well. I will add a comment to the >> field tha

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi Andrew, On 2018-09-27 15:28, Andrew Haley wrote: > On 09/27/2018 01:23 PM, Raffaello Giulietti wrote: > >> In principle I agree with you. >> >> However, in this case the maths underlying the algorithm to select the >> decimal are too involved to explain in c

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2018-09-27 16:55, Andrew Dinn wrote: Hi Raffaello, On 27/09/18 15:20, raffaello.giulie...@gmail.com wrote: Hi Andrew, On the other side, in April this year I submitted another quite fast and supposedly correct algorithm on this mailing list and I referred to an accompanying paper by myself

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi Ulf, On 2018-09-27 16:40, Ulf Adams wrote: Hi Raffaello, I am the author of a recent publication on double to string conversion [1] - the Ryu algorithm. I've been aware of the problems with the Jdk for several years, and am very much looking forward to improvements in correctness and

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2018-09-27 17:53, Andrew Dinn wrote: On 27/09/18 16:37, Raffaello Giulietti wrote: . . . I thank you in advance for your willingness to review the code but my understanding is that only the officially appointed reviewers can approve OpenJDK contributions, which is of course a good policy

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2019-03-08 14:35, Andrew Haley wrote: > Hi, > > On 3/7/19 7:16 PM, Raffaello Giulietti wrote: > >> a couple of weeks ago I tried to refactor the code assuming the >> existence of unsignedMultiplyHigh() (either as some future intrinsic or >> as a Java method) an

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

On 2019-03-07 11:10, Brian Burkhalter wrote: On Mar 7, 2019, at 10:04 AM, Andrew Haley > wrote: On 3/6/19 7:31 PM,raffaello.giulie...@gmail.com wrote: the latest version of the patch, replacing the one found at [1]. In the next

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Greetings Raffaello Kind regards Anthony *From:* core-libs-dev on behalf of Raffaello Giulietti *Sent:* Monday, May 6, 2019 2:08:48 PM *To:* core-libs-dev *Subject:* [PATCH] 4511638: Double.toString(double) sometimes p

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi, On 18.04.19 21:29, Brian Burkhalter wrote: On Apr 18, 2019, at 11:44 AM, Raffaello Giulietti <mailto:raffaello.giulie...@gmail.com>> wrote: here's another revision of the patch. Its purpose is to overcome the test failure observed in [1]. To this end, the p

Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

n in java.io.IOError? From: core-libs-dev on behalf of Raffaello Giulietti Sent: Thursday, April 18, 2019 3:37 PM To: Brian Burkhalter; core-libs-dev Subject: Re: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results Hi, On 1

[PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

Hi, no new code this time, only a warm invitation to review the rather substantial patch submitted on 2019-04-18 [1] and the CSR [2]. I spent an insane amount of (unpaid) free time offering my contribution to solve a bug known since about 15 years. Thus, I think it is understandable that

GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

Hi, just a gentle reminder for a RFR of [1] (see [5] for the original request). An efficient implementation can be found on [2] and in Brian Burkhalter's webrev area [3]. This also requires a review. The full details are discussed in [4]. Greetings Raffaello [1]

Re: Are classes generated by LambdaMetafactory special?

those classes as non-modifiable. This may change in the future. Rémi - Mail original - De: "raffaello giulietti" À: "core-libs-dev" Envoyé: Lundi 5 Août 2019 23:02:48 Objet: Are classes generated by LambdaMetafactory special? Hello, experiment suggests th

Are classes generated by LambdaMetafactory special?

Hello, experiment suggests that classes generated by java.lang.invoke.LambdaMetafactory are somewhat special: (1) getName() on the class returns a string of the form Xxx$$Lambda$nn/0xhhh where Xxx is a fully qualified class name (with periods '.' as package separators), nn is a decimal

Are classes generated by LambdaMetafactory special?

he name of a proxy class is only useful for >troubleshooting but entirely not needed at runtime. > >Mandy > >On 8/5/19 2:51 PM, Raffaello Giulietti wrote: >> Thanks Rémi and Mandy. >> >> I still don't get the full rationale on why lambda classes should be &g

RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

Hi folks, as nothing has substantially moved towards approval of the patch [1] and the corresponding CSR [2], let's split the issue into its constituents. The CSR is currently finalized and needs a further review for approval. This requires much less time than a review of the implementation

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

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

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

. 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

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

Hello, great job! I think that the doc of MemoryAddress.copy() should be explicit about the direction of the copying, so it should either: * explicitly specify a direction, e.g., lower-to-higher addresses * or specify that in the case of an overlap the copying is smart enough to not

Re: RFR JDK-8234049: Implementation of Memory Access API (Incubator)

Hi, MemoryLayouts exposes BITS_8_BE and BITS_8_LE. Is there a reason to have both or is just love for symmetries (which I share)? Greetings Raffaello > Hi, > as part of the effort to upstream the changes related to JEP 370 (foreign memory access API) [1], I'd like to ask for a code

Re: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

Since nothing seems to have moved, here's the familiar monthly reminder ;-) Greetings Raffaello On 2019-08-30 10:47, Raffaello Giulietti wrote: Hi, just a gentle reminder for a RFR of [1] (see [5] for the original request). An efficient implementation can be found on [2] and in Brian

wavl based alternative to red-black TreeMap

Hi core librarians, did anybody already explore wavl trees as a drop-in replacement to the red-black based TreeMap? If yes, I'm curious about performance comparisons. If not, I would be glad to invest some time on it as they seem to be never worse than red-black trees and in many

wavl based alternative to red-black TreeMap

tree, worth the exploration i believe. and TreeMap code really needs some love anyway, unlike ArrayList and HashMap, this code has not be updated since a long time. Rémi [1] https://en.wikipedia.org/wiki/WAVL_tree - Mail original - De: "raffaello giulietti" À: "core-li

request for sponsor: wavl based alternative to red-black TreeMap

Hello, is anybody interested in sponsoring me on exploring a wavl tree implementation of TreeMap [1]? For some reason related to gmail, I'm not able to get messages targeted to the mailing list alone, so please cc: me as well. Greetings Raffaello (Here are some highlights of wavl trees:

Re: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

Yet another monthly reminder. The December rampdown is approaching... Greetings Raffaello On 2019-10-29 20:33, Raffaello Giulietti wrote: Since nothing seems to have moved, here's the familiar monthly reminder ;-) Greetings Raffaello On 2019-08-30 10:47, Raffaello Giulietti wrote: Hi

Why you want a better specification and a fast implementation of Double.toString(double)

Hi, I'd like this community to help me pushing a new spec and the accompanying implementation of Double.toString(double) and Float.toString(float) into the OpenJDK 14 release. All material has already been submitted to this mailing list months ago [2] and passes tier 1 tests. Yet, there

GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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/

REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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]

GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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]

Re: GENTLE REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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.

Unexpected behaviour with larger Strings

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

17.7x speedup of Double.toString(double)

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,

REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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]

trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

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 +++

Re: trivial correction to javadoc of j.l.i.MethodHandles.arrayElementVarHandle()

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

Re: REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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

Re: REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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

REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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

Re: RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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>>

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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.

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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

Re: RFR 8251989: Hex formatting and parsing

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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

RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic)

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v3]

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2]

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2]

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

RFR 8251989: Hex encoder and decoder utility

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

Re: RFR 8251989: Hex encoder and decoder utility

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

Re: RFR 8251989: Hex encoder and decoder utility

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

RFR 8251989: Hex encoder and decoder utility

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,

RFR 8251989: Hex encoder and decoder utility

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

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2]

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

Re: contributing to JDK-8171407: Port fdlibm to Java, part 2

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

Re: contributing to JDK-8171407: Port fdlibm to Java, part 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

REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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

contributing to JDK-8171407: Port fdlibm to Java, part 2

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

Re: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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

[15] 8235792: LineNumberReader.getLineNumber() behavior is inconsistent with respect to EOF

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

Re: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

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

Re: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

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

Re: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

# 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

Re: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

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

Re: RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

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

Reminder RFR: 8245036: DataInputStream.readFully(byte[], int, int) does not throw expected IndexOutOfBoundsExceptions

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

Re: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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

RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

# 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

Re: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

# 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

RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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

Re: RFR: JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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

Re: Math.mutiplyHigh() is signed

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

java.util.Base64 accepts non-canonical encodings

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

Re: java.util.Base64 accepts non-canonical encodings

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

Exceptions priority in InputStream.read(byte[], int, int)

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

java.util.Base64 accepts non-canonical encodings

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

Contributing to JEP 356: Enhanced Pseudo-Random Number Generators ?

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

Schubfach adoption + RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results

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

Re: contributing to JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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

Re: Contributing to JEP 356: Enhanced Pseudo-Random Number Generators ?

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

contributing to JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

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]

  1   2   3   4   >