Java Hexadecimal Floating Point Literal Ambiguity

Question

In Java specification, it says the following:

For hexadecimal floating-point literals, at least one digit is required (in either the whole number or the fraction part), and the exponent is mandatory, and the float type suffix is optional. The exponent is indicated by the ASCII letter p or P followed by an optionally signed integer.

As I understand, the exponent indicating letter has to be p or P to resolve ambiguity with the hexadecimal digit e or E. Why does it then say that the suffix indicating type (float vs double) is optional, when using it would introduce ambiguity with letters d, D, f, F, which are also hexadecimal digits?

Answer 1

According to the grammar:

DecimalFloatingPointLiteral:
  Digits . [Digits] [ExponentPart] [FloatTypeSuffix] 
  . Digits [ExponentPart] [FloatTypeSuffix] 
  Digits ExponentPart [FloatTypeSuffix] 
  Digits [ExponentPart] FloatTypeSuffix

HexadecimalFloatingPointLiteral:
  HexSignificand BinaryExponent [FloatTypeSuffix]

the optional FloatTypeSuffix must follow the mandatory BinaryExponent for a hex floating point number.

If you add an f or a d without a BinaryExponent, it's a decimal floating point number.

Answer 2

The hexadecimal form is to make the mantissa precise. The exponent is a whole number and can be represented as a decimal precisely so doesn't have a conflict with letters d or f.

A normalised floating point number is of the form

sign * 1.mantissa * 2 ^ exponent

If you look at these examples, it is expected that the hexa-decimal notation is used when specifying the mantissa exactly.

// from java.lang.Double

public static final double MAX_VALUE = 0x1.fffffffffffffP+1023; // 1.7976931348623157e+308

public static final double MIN_NORMAL = 0x1.0p-1022; // 2.2250738585072014E-308

public static final double MIN_VALUE = 0x0.0000000000001P-1022; // 4.9e-324

In this form it is easy to see the expected mantissa and exponent. While other forms are possible they are not as clear.