|
From: | Bryce McKinlay |
Subject: | Re: classpath ./ChangeLog java/lang/Double.java |
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.
regards Bryce.
[Prev in Thread] | Current Thread | [Next in Thread] |