This is a defect in the ER5 implementation of the Java VM. Under EPOC Release 5, the above Java calls cause a standard C function atof() to be executed. This in turn makes use of the EPOC function TLex8.Val() which expects the decimal point to be as specified in the "International |Number" setting. If this setting is other than ".", the parsing fails and a NumberFormatException gets returned. See also
Note that you cannot get round this by changing the decimal separator in the parsed Java string as these Java methods only work (and should only work) with ".". The problem can be worked around by Java developers by preparing a Java wrapper function for a direct call through the JNI mechanism to the following code. This wrapper would be used in place of the defective Float.valueOf(). Using this function and the Float(float) constructor, a new Float could then be straightforwardly constructed from a string if wished.
_LIT(KRealNumber, "1001.12345"); // input the string
// in a JNI function call this would typically be received as a jstring
TReal32 aResult; // or use TReal64 for double precision
TLex lex(KRealNumber); // create a TLex object which can be parsed
TInt err = lex.Val(aResult,'.'); // parse the given string as a TReal
return aResult;