Why is there a “d” in the definition of Double.NaN = 0.0d / 0.0?

Question

I just came across the definition of NaN in Double.class. It says:

 /**
   * A constant holding a Not-a-Number (NaN) value of type
         


        

Answer 1

There is no difference between 0.0 and 0.0d as Java takes doubles by default to represent floating point numbers.

Still, the code is more readable as in many languages, float is the default as well as it was in Oak later evolved to become Java so it looks like historical issue.

--Link found by Andy Turner.

Answer 2

According to the language specification, 0.0 is the same as 0.0d

JLS Section 3.10.2 describes this as follows:

A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d

One of the ways of making a literal number floating point, is by using a '.' in the number.

Why the writers use the d suffix is not known. But often this is to add clarity or reduce the amount of effort required from the reader when understanding this code. The rules might be known to some people, but not to everyone. The defaults could also be different for other languages. Hence in many cases writing a more verbose version is better.

Another example of this is parentheses:

 double a = b + c * d;

vs

 double a = b + (c * d);

I prefer the one with parentheses, because it is easier to read (even if all programmers know they are equal).

Answer 3

According to the Oak language spec, the format of floating point literals were:

• 2.0d or 2.0D double
• 2.0f or 2.0F or 2.0 float

but this changed to the familiar Java way by Java version 1.0

A floating-point literal is of type float if it is suffixed with an ASCII letter F or f; otherwise its type is double and it can optionally be suffixed with an ASCII letter D or d.

The change was perhaps made to make it consistent with C-like languages, where the lack of suffix means a double.

So the d appears to be an historical relic; although, in the linked version of the Oak spec (which is "preliminary"), there is a margin note saying that NaN isn't implemented yet. Perhaps it was implemented in a slightly later version, and has remained the same forever after.

(Props to Mark Rotteveel for the nudge to look up the Oak language spec).