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

[raffaello.giulietti at gmail.com]

Hi Brian,

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 [1] issue is [2]. 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. [3]
> 

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 [4].
> 

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 [5] 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 [6].
> 

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.



> 
> [1] https://wiki.openjdk.java.net/display/general/JBS+Overview
> [2] https://bugs.openjdk.java.net/browse/JDK-4511638
> [3] https://wiki.openjdk.java.net/display/csr/Main
> [4] http://openjdk.java.net/contribute/
> [5] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-March/000940.html
> [6] http://openjdk.java.net/guide/codeReview.html