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

[Magnus Ihse Bursie]

> 17 apr. 2018 kl. 00:52 skrev mark.reinh...@oracle.com:
> 
> 2018/4/12 1:12:36 -0700, raffaello.giulie...@gmail.com:
>> 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 today, I got no answer.
>> 
>> Is there any official reference about the copyright notice on OpenJDK 
>> contributions?
> 
> For library code, the template is in $JDK/make/templates/gpl-cp-header [1].
> It begins:
> 
>  Copyright (c) %YEARS% Oracle and/or its affiliates. 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 GNU General Public License version 2 only, as
>  ...
> 
> You can just use the Oracle copyright line or, at your option, replace
> it with your own.  In any case %YEARS% should be replaced with the year
> in which the file was created, and if it was modified in any later year
> then the creation year should be followed by the latest year in which
> the file was modified, separated by a comma.

The Oracle praxis is that the year or years should still be followed by a 
comma. E.g:

 Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved.
or
 Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved.

I don’t know if this is an Oracle quirk or and (in)official OpenJDK 
requirement, but it probably doesn’t harm to follow it. :-)

/Magnus

> 
> (We can better advise you on the details once we see the actual code.)
> 
> - Mark
> 
> 
> [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header

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

[Raffaello Giulietti]

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 2018-04-17 00:52, mark.reinh...@oracle.com wrote:

2018/4/12 1:12:36 -0700, raffaello.giulie...@gmail.com:

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 today, I got no answer.

Is there any official reference about the copyright notice on OpenJDK
contributions?


For library code, the template is in $JDK/make/templates/gpl-cp-header [1].
It begins:

   Copyright (c) %YEARS% Oracle and/or its affiliates. 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 GNU General Public License version 2 only, as
   ...

You can just use the Oracle copyright line or, at your option, replace
it with your own.  In any case %YEARS% should be replaced with the year
in which the file was created, and if it was modified in any later year
then the creation year should be followed by the latest year in which
the file was modified, separated by a comma.

(We can better advise you on the details once we see the actual code.)

- Mark


[1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header

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

[mark . reinhold]

2018/4/12 1:12:36 -0700, raffaello.giulie...@gmail.com:
> 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 today, I got no answer.
> 
> Is there any official reference about the copyright notice on OpenJDK 
> contributions?

For library code, the template is in $JDK/make/templates/gpl-cp-header [1].
It begins:

  Copyright (c) %YEARS% Oracle and/or its affiliates. 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 GNU General Public License version 2 only, as
  ...

You can just use the Oracle copyright line or, at your option, replace
it with your own.  In any case %YEARS% should be replaced with the year
in which the file was created, and if it was modified in any later year
then the creation year should be followed by the latest year in which
the file was modified, separated by a comma.

(We can better advise you on the details once we see the actual code.)

- Mark


[1] http://hg.openjdk.java.net/jdk/jdk/file/tip/make/templates/gpl-cp-header

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

[David Holmes]

On 16/04/2018 11:22 PM, Mario Torre wrote:

2018-04-12 10:12 GMT+02:00 Raffaello Giulietti :


I asked Oracle about how the copyright notice should be adapted to meet the
OCA requirements but, as of today, I got no answer.


All the headers need to have a valid copyright text, you can just copy
the headers from any other file in the OpenJDK sources, as they are
all the same (just keep attention to the year, as this may not always
be up to date).


That's not true Mario. Files from different sources have different 
copyrights. Those that originated outside Oracle have non-Oracle 
copyrights. Some have dual copyrights.



The license and other useful things are explained here:

http://openjdk.java.net/legal/


None of that explains how to formulate the initial copyright header for 
sources added to OpenJDK.


Cheers,
David


Cheers,
Mario

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

[Mario Torre]

2018-04-12 10:12 GMT+02:00 Raffaello Giulietti :

> I asked Oracle about how the copyright notice should be adapted to meet the
> OCA requirements but, as of today, I got no answer.

All the headers need to have a valid copyright text, you can just copy
the headers from any other file in the OpenJDK sources, as they are
all the same (just keep attention to the year, as this may not always
be up to date).

The license and other useful things are explained here:

http://openjdk.java.net/legal/

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

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

[Thomas Stüfe]

On Sat, Mar 31, 2018 at 12:17 AM, Brian Burkhalter
 wrote:
> Hi Raffaello,
>
> On Mar 30, 2018, at 2:57 PM, raffaello.giulie...@gmail.com wrote:
>
 […]

 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.99E22"
>> issue. Everything else is worded in such a way to remain compatible but
>> is simply a little bit more rigorous.
>
> Sounds good.
>
>> My wording was misleading: I already got the confirmation that my OCA
>> application has been accepted, so I'm formally ready to contribute.
>
> That’s good as it gives more time.
>
>>> 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.
>
> As seen in Jon’s posting there are some attachment types which will work. As 
> to webrev, I think it should work on Windows at least in cygwin but I’ve not 
> used it there myself. If it’s just a matter of creating a webrev I could do 
> that on your behalf based on your supplied patch.
>

Just to chime in here, producing webrevs on windows is easy:

- in cygwin, install Korn shell (ksh)
- and, of course, mercurial

the rest is standard:
- clone the code-tools/webrev repo:
http://hg.openjdk.java.net/code-tools/webrev/
- run webrev: ksh /webrev.ksh -o 

Best Regards, Thomas

> Thanks,
>
> Brian

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

[Raffaello Giulietti]

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 today, I got no answer.


Is there any official reference about the copyright notice on OpenJDK 
contributions?



Greetings
Raffaello




On 2018-03-31 00:17, Brian Burkhalter wrote:

Hi Raffaello,

On Mar 30, 2018, at 2:57 PM, raffaello.giulie...@gmail.com 
 wrote:



[…]

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.99E22"
issue. Everything else is worded in such a way to remain compatible but
is simply a little bit more rigorous.


Sounds good.


My wording was misleading: I already got the confirmation that my OCA
application has been accepted, so I'm formally ready to contribute.


That’s good as it gives more time.


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.


As seen in Jon’s posting there are some attachment types which will 
work. As to webrev, I think it should work on Windows at least in cygwin 
but I’ve not used it there myself. If it’s just a matter of creating a 
webrev I could do that on your behalf based on your supplied patch.


Thanks,

Brian

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

[Brian Burkhalter]

Hi Raffaello,

On Mar 30, 2018, at 2:57 PM, raffaello.giulie...@gmail.com wrote:

>>> […]
>>> 
>>> 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.99E22"
> issue. Everything else is worded in such a way to remain compatible but
> is simply a little bit more rigorous.

Sounds good.

> My wording was misleading: I already got the confirmation that my OCA
> application has been accepted, so I'm formally ready to contribute.

That’s good as it gives more time.

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

As seen in Jon’s posting there are some attachment types which will work. As to 
webrev, I think it should work on Windows at least in cygwin but I’ve not used 
it there myself. If it’s just a matter of creating a webrev I could do that on 
your behalf based on your supplied patch.

Thanks,

Brian

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

[raffaello . giulietti]

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
>> 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.99E22"
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

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

[Brian Burkhalter]

Thanks, Jon!

On Mar 30, 2018, at 1:54 PM, Jonathan Gibbons  
wrote:

> See 
> http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html
> for the original.

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

[Jonathan Gibbons]

On 03/30/2018 01:42 PM, Brian Burkhalter wrote:

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


Brian,

From another mailing list:


Most OpenJDK mailing lists, including this one (code-tools-dev),
allow these attachment types:

   text/plain
   text/x-diff
   text/x-patch
   message/rfc822

Attachments with the following filename extensions are dropped:

   exe
   bat
   cmd
   com
   pif
   scr
   vbs
   cpl

- Mark


See 
http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html

for the original.

-- Jon

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

[Brian Burkhalter]

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

> […]
> 
> 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]

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

> I've already signed the Oracle Contributor Agreement a few days ago.

Processing the OCA should take at least two weeks [4].

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

Thanks,

Brian

[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