Re: classpath ./ChangeLog java/lang/Double.java

[Tom Tromey]

>>>>> "Brian" == Brian Jones <address@hidden> writes:

Brian> parseDouble is now completely native, which means the previous
Brian> code that did a trim in Java and would have thrown the
Brian> NullPointerException is no longer there.  I still don't get why
Brian> Tom wanted to do the trim in a native method.

My goal was to reduce divergence between Classpath and libgcj.  I
didn't want to use the Classpath code here because it allocated a new
String.

Brian> In java_lang_Double.c, we do GetStringUTFChars on the null
Brian> object. which did not throw a NullPointerException using ORP at
Brian> least.  According to the JNI specification that method only
Brian> throws OutOfMemoryError so maybe this is normal behavior.

As I recall the JNI spec is pretty lenient.  An implementation can
assume that the user won't make mistakes.  For instance simply
crashing in this situation is probably acceptable.

Brian> In the official Javadoc for Double (String) and parseDouble
Brian> (String) each is said to only throw NumberFormatException
Brian> whereas Double.valueOf is documented to throw the runtime
Brian> exception NullPointerException.  So doing so explicitly in this
Brian> method (a) matches the Javadoc and (b) passes Mauve's tests.

The docs are generally pretty bad about mentioning
NullPointerException.  You can't really trust them on this issue.

Another fix in this particular case would be to have parseDouble()
throw NullPointerException if the String is null.  The libgcj
implementation will already do this.

A simple test (appended) shows that JDK 1.2 at least throws
NullPointerException from parseDouble.

Tom

public class t
{
  public static void main (String[] args)
  {
    System.out.println (Double.parseDouble (null));
  }
}