Clean-room implementation of Double::toString(double) and Float::toString(float)
raffaello.giulietti at gmail.com
raffaello.giulietti at gmail.com
Fri Mar 30 21:57:30 UTC 2018
On 2018-03-30 22:42, Brian Burkhalter wrote:
> Hello Raffaello,
> On Mar 30, 2018, at 9:50 AM, raffaello.giulietti at gmail.com
> <mailto:raffaello.giulietti at gmail.com> wrote:
>> 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 report still remain unsolved in the
>> latest OpenJDK.
> The JBS  issue is . It is currently owned by me.
Yes, and the submission of the report was mine, far more than 10 years
ago. Guys, time passes too fast...
>> The new code also has a better specification than the current one, while
>> being mostly compatible. Indeed, the current specification leaves room
>> for interpretation and thus cannot ensure that an implementation
>> produces consistent and unique results from one release to the next. The
>> newer spec ensures a unique result.
> Any specification change would need to go through the Compatibility and
> Specification Review process. 
OK, as you will see, as soon as the code will be uploaded, the only
thing that formally affects output is the "1.0E23" versus "9.99....E22"
issue. Everything else is worded in such a way to remain compatible but
is simply a little bit more rigorous.
>> If there is interest in the new implementation, I would be glad to
>> contribute my code to the OpenJDK.
> Speaking for myself, any contribution in this area would be welcome.
> Work could proceed under the extant JBS bug ID.
OK, let's to that.
>> I've already signed the Oracle Contributor Agreement a few days ago.
> Processing the OCA should take at least two weeks .
My wording was misleading: I already got the confirmation that my OCA
application has been accepted, so I'm formally ready to contribute.
>> The code currently sits in its own module, is mostly polished,
>> thoroughly tested but has never been audited by people other than myself.
>> My target is to be able to integrate it in the JDK 11 LTS release, due
>> in late September 2018.
> Per the JDK 11 schedule  there could well be sufficient time to run
> this submission through the review processes. I suggest, once your OCA
> has been processed, to proceed by posting your proposed changes for
> review on this mailing list. Note that in general attachments are
> scrubbed, so the patch would need either to be included inline or
> published as a webrev .
OK, I'll take a look on how the mechanics works.
I'm usually on Windows. Are there technical issues with it as far as
Webrev is concerned? I mean, I could setup a Linux VM in VirtualBox if
this simplifies my life, but I'd prefer continuing my main work in Win.
>  https://wiki.openjdk.java.net/display/general/JBS+Overview
>  https://bugs.openjdk.java.net/browse/JDK-4511638
>  https://wiki.openjdk.java.net/display/csr/Main
>  http://openjdk.java.net/contribute/
>  http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000940.html
>  http://openjdk.java.net/guide/codeReview.html
More information about the core-libs-dev