java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)


Parsing double literals very near the exact halfway point of the cutoff for
denormalized numbers has some problems.  This cutoff can be determined as the
average of Double.longBitsToDouble(0x0010000000000000L) and
Double.longBitsToDouble(0x000fffffffffffffL), using the precise math of
java.math.BigInteger.  The halfway point must round up, according to IEEE 754
round-to-nearest rules.

With this example, the literal is larger than the lines - be sure that there are
no line breaks in the actual number when compiling.

Basically, appending a non-zero extension at the end of the literal
causes java.lang.Double.parseDouble to enter an infinite loop.  As javac
uses this library call, it is impossible to compile this example:

class Literal {
  public static void main(String[] args) {
    System.out.println(
0.000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000022250738585
07201136057409796709131975934819546351645648023426109724822222021076945516529523
90813508791414915891303962110687008643869459464552765720740782062174337998814106
32673292535522868813721490129811224514518898490572223072852551331557550159143974
76397983411801999323962548289017107081850690630666655994938275772572015763062690
66333264756530000924588831643303777979186961204949739037782970490505108060994073
02629371289589500035837999672072543043602840788957717961509455167482434710307026
09144621572289880258182545180325707018860872113128079512233426288368622321503775
66662250398253433597456888442390026549819838548794829220689472168983109969836584
68140228542433306603398508864458040010349339704275671864433837704860378616227717
38545623065874679014086723327636718751
);
  }
}

However, remove the final 1, and the class compiles just fine.  Unfortunately,
it gives the output of 2.225073858507201E-308, intead of the correct
2.225073858507201E-308, meaning that it rounded down instead of up.
(Review ID: 118067) 
======================================================================
  xxxxx@xxxxx   2004-11-11 21:44:14 GMT

Don't use either double in question (the exact halfway point or something near
it).  Instead, use a shorter literal that is closer to the desired double
value, rather than abusing round-to-nearest rules.
======================================================================

Verified problem still exists in Merlin FCS; should be fixed.

  xxxxx@xxxxx   2002-05-28

Decomitting from Tiger, problem should still be fixed in a future release.

  xxxxx@xxxxx   2003-09-08

Oops - I just caught a typo in my report.  The correct value
of the halfway point should be 2.2250738585072014E-308 (I
left out the final 4).

The problem can be fixed by changing a line "java.lang.FloatingDecimal.java:1514" in J2SE 1.4.2
from:
		    if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){
to:
		    if ( (bigIntNBits == 1) && (bigIntExp > -expBias+1) ){
.