Is there a difference when using Java Double.parseDouble and the same method in Android?

Question

The reason I ask is because I have 2 exact same bits of code in an android app and in a java program doing the same thing (collecting tidal data):

String[] string4 = tide4.replaceAll("[LmH]", "").split(" ");
         Time4 = string4[0];
         String height4 = string4[1].replaceAll("\\s", "");

         System.out.println("HEIGHT4 = " + "'" + height4 + "'" );

        //Convert the Meters into feet for tide heights
      double heightM4 = Double.parseDouble(height4); //FAILS ON THIS LINE IN **JAVA** NOT IN ANDROID

Exception: java.lang.NumberFormatException: For input string: "6.24 "

However in the java program running on my machine it fails when parsing it? in Android it carries on fine. I have noticed one thing different when testing. When printing the value of "height4" in eclipse on my machine it outputs something like this: HEIGHT4 = '6.24 ' <--Notice the space! In Android it outputs this: HEIGHT4 = '6.24'<--No Space? Nothing is different between the 2 bits of code except the platform they are running on( as far as I can see). What could the cause of this be? Something to do with that un-removable whitespace?

so what you are saying is that the method behaves differently when given different inputs? apparently either `replaceAll` is actually different, or the content of `tide4` is not the same — njzk2, Dec 03 '14 at 22:45
Hi, there both the same in the Java version and Android I have checked multiple times im sure of it, they are collecting the same data using the same bits of code. — J4C3N-14, Dec 03 '14 at 22:47
What about writing a unit test, and let it run on both plattforms with the exact same input. And yes, android java is not sun java, but hopefully behave the same, but your problem is related to replaceAll, which produce the additional space, not the parseDouble() — AlexWien, Dec 03 '14 at 22:50
Altough your Problem is not the parseDouble, I can tell you that IBM Embedded Java J9 (1.3) implementtaion of parseDouble() cannot parse "Infinity" while sun java can. — AlexWien, Dec 03 '14 at 22:57
@AlexWien Hi, thanks for pointing out that it is replaceAll, any ideas why replaceAll isn't replacingAll — J4C3N-14, Dec 03 '14 at 22:57
Either different input (maybe LineFeeds in File: Android is Linux based, while your PC probably is Windows) or different implementtaion of replaceAll. — AlexWien, Dec 03 '14 at 23:00
To solve: chnage to this: Double.parseDouble(height4.trim()); That removes spaces. — AlexWien, Dec 03 '14 at 23:02
Just tried it, sorry didn't work?, still outputs with that space — J4C3N-14, Dec 03 '14 at 23:04

score 1 · Accepted Answer · edited May 23 '17 at 11:50

What could the cause of this be? Something to do with that un-removable whitespace?

I think it is everything to do with that mysterious character. It is clearly not a digit or one of the other characters that are valid in a number, and that would definitely result in a parse error.

What you need to do is to use a debugger or some trace printing to find out what the mysterious character is. For example:

    char last = height4.charAt(height4.length() - 1); 
    System.out.println("The last character codepoint is " + ((int) last));

then convert the codepoint to hexadecimal and look it up in the Unicode tables at http://unicode.org

Once you have done that, you can figure out where the mystery is coming from and / or what is the best way to get rid of it.

Advice: If I would you, I would focus on figuring out where the character is coming from. The fact that you are getting strange stuff is a worry, and points to the potential for other problems. If you just try to get rid of the bad stuff, then you may be sweeping a larger problem under the carpet; e.g. making it harder to find.

UPDATE - The 0x00A0 code point is the "non-breaking space" (NBSP) character in the LATIN-1 supplement:

The String.trim() method doesn't remove this. It only removes ASCII control codes; i.e. 0x0000 through 0x0020.
In the regex language implemented by Pattern, "\\s" doesn't match all Unicode space variants. This Question has the solution: Java regular expression to match _all_ whitespace characters

The presence of a NBSP is not as problematic as "random characters", but it suggests that you are "scraping" your input from rendered text (e.g. HTML) and there are differences in the rendering or scraping processes between the two platforms. While not worrying per se, this is something you need to keep in mind.

Hi, Thank you for the helpful answer. The codepoint is 160, which is \u00A0. — J4C3N-14, Dec 03 '14 at 23:32
Success, replacing \u00A0 and it now works. Thank you. But, could you offer any reason why doesn't work, i thought it was the same? also why would it be handled differently on Android? it has already been mentioned that Android Java is different from Sun Java so is it down to that? Thanks for the guidance. — J4C3N-14, Dec 03 '14 at 23:38
Thank you for the update on the answer, very helpful! especialy for an amature with no teacher, just text! Stillgotahellofalottolearn. — J4C3N-14, Dec 04 '14 at 00:45

Is there a difference when using Java Double.parseDouble and the same method in Android?

1 Answers1