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

[Bryce McKinlay]

Brian Jones wrote:

> > Why? This shouldn't be neccessary.
>
> Double.valueOf (String)
> calls->new Double (String)
> calls->parseDouble (String)
>
> parseDouble is now completely native, which means the previous code
> that did a trim in Java and would have thrown the NullPointerException
> is no longer there.  I still don't get why Tom wanted to do the trim
> in a native method.
>
> In java_lang_Double.c, we do GetStringUTFChars on the null
> object. which did not throw a NullPointerException using ORP at
> least.  According to the JNI specification that method only throws
> OutOfMemoryError so maybe this is normal behavior.
>
> In the official Javadoc for Double (String) and parseDouble (String)
> each is said to only throw NumberFormatException whereas
> Double.valueOf is documented to throw the runtime exception
> NullPointerException.  So doing so explicitly in this method (a)
> matches the Javadoc and (b) passes Mauve's tests.

Double.valueOf(String), new Double(String), and 
Double.parseDouble(String) should all throw NullPointerException if a 
null argument is given. Most methods actually seem to behave this way 
even though it isn't explicitly specified in the spec - usually we can 
assume it is the default behaviour if nothing else is specified.

In libgcj, parseDouble will throw if it is given a null argument, so 
checks in valueOf and the constructor are unneccessary since they 
eventually call parseDouble(). So, parseDouble do the check (which I 
assume is neccessary in JNI?) in order to maintain synchronization 
between the libgcj and classpath versions of Double, and so that 
parseDouble matches the behaviour of the JDK.

regards

Bryce.