[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: classpath ./ChangeLog java/lang/

From: Bryce McKinlay
Subject: Re: classpath ./ChangeLog java/lang/
Date: Fri, 16 Nov 2001 09:25:39 +1300
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.5) Gecko/20011016

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]