Locale, Formatter und Scanner: Bug bei Gleitkommazahlen?

[Ark]

Hallo, allerseits,

ich bastle gerade an diesem FAQ-Beitrag rum, und mir ist schon beim Schreiben etwas aufgefallen, das für mich wie ein Fehler aussieht, zumindest in meiner Java-Version:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)

Im genannten Beitrag stelle ich Formatter und Scanner vor, um Gleitkommazahlen vom Anwender eingeben zu lassen bzw. für ihn wieder auszugeben. Allerdings scheint das zusammen mit Locale.GERMAN nur mit "%f" beim Formatter problemlos zu funktionieren. Bei "%g" und "%e" werden Dezimalpunkte statt -kommata verwendet, die der Scanner wiederum nicht mag. Folgender Code verdeutlicht dies:

[java=41] private static void bugOrFeature(){
final double[] value = new double[]{
0.0, -0.0, Double.NaN, Double.NEGATIVE_INFINITY,
Double.POSITIVE_INFINITY, Math.PI, 123456, 123456e20
};
final String[] format = new String[]{
"%f", "%g", "%e"
};

for(final String f : format){
System.out.println(f);
for(final double d : value){
System.out.print(d + "\t");
String s = new Formatter(Locale.GERMAN).format(f, d).out().toString();
// s = s.replaceAll("\\.", ","); // workaround
System.out.print(s + "\t");
final double si = new Scanner(s).useLocale(Locale.GERMAN).nextDouble();
System.out.println(si);
}
System.out.println();
}
}[/code]
Bei mir kommt es zu folgendem Fehler:

%f
0.0	0,000000	0.0
-0.0	-0,000000	-0.0
NaN	NaN	NaN
-Infinity	-Infinity	-Infinity
Infinity	Infinity	Infinity
3.141592653589793	3,141593	3.141593
123456.0	123456,000000	123456.0
1.23456E25	12345600000000000000000000,000000	1.23456E25

%g
0.0	0.00000	Exception in thread "main" java.util.InputMismatchException
	at java.util.Scanner.throwFor(Scanner.java:840)
	at java.util.Scanner.next(Scanner.java:1461)
	at java.util.Scanner.nextDouble(Scanner.java:2387)
	at Test.bugOrFeature(Test.java:57)
	at Test.main(Test.java:38)

Wenn man im Code die Zeile mit dem Kommentar "workaround" aktiviert, kommt kein Fehler mehr und der Scanner interpretiert auch jedes Komma korrekt. Für mich sieht das nach einem Fehler im Formatter aus, immerhin heißt es z.B. zu "%e" in der Dokumentation:

Requires the output to be formatted using computerized scientific notation. The localization algorithm is applied.
[…]
The magnitude is then represented as the integer part of a, as a single decimal digit, followed by the decimal separator followed by decimal digits representing the fractional part of a, followed by the exponent symbol 'e' ('\u0065'), followed by […]

(Hervorhebungen von mir.)

Weiß jemand, ob es sich tatsächlich um einen Bug oder um ein Feature handelt? Und wie sieht das in Java 7 aus? Ich habe zwar Suchmaschinen bemüht, aber zumindest ich konnte hierzu keine konkreten Hinweise finden (außer z.B. ähnliche Schwierigkeiten im Zusammenhang mit JTable etc.).

Ark

 

[planetenkiller]

Weiß jemand, ob es sich tatsächlich um einen Bug oder um ein Feature handelt?

Ich tendiere ja eher zu Bug:
Source Code von Formatter:
Bei %f
[java=3227]
localizedMagnitude(sb, mant, f, newW, l); // l=Locale
[/code]

bei %g
[java=3264]
localizedMagnitude(sb, mant, f, newW, null); // null als Locale?
[/code]

Und wie sieht das in Java 7 aus?

Bei Java7 wurde es wohl gefixt:
jdk7/jdk7-gate/jdk: src/share/classes/java/util/Formatter.java@501ca93ea3ef Zeilen 3308 & 3271 & 3235

 

[Ark]

Vielen, vielen Dank. Ich habe mir zwar die Quelltexte meiner Version etwas angeguckt, aber konnte spontan keinen Fehler finden. Leider habe ich beim Verlinkten nicht die Revision finden können, mit der der Fehler behoben wurde … ???:L

Da ich gerade kein JDK 7 habe (und auch nicht in absehbarer Zeit installieren werde - über Neuerungen informiere ich mich natürlich trotzdem ), würde es mich freuen, wenn jemand mit JDK 7 (z.B. durch Ausführen des Codes oben) bestätigen könnte, dass der Fehler tatsächlich behoben wurde.

Ark