Java BigDecimal Möglicher Überlauffehler

Lesezeit: 2 Minuten

Benutzer-Avatar
DJMatch3000

Ich habe Randbedingungen für einen Code getestet, an dem a beteiligt war BigDecimalund das ist mir aufgefallen, als a BigDecimal wird mit dem String initialisiert "1e2147483647" es verhält sich unerwartet. Es scheint einen Wert zwischen zu haben 0 und 1e-2147483647. Wenn ich versuche anzurufen intValue()Ich bekomme ein NegativeArraySizeException. Das sollte ich beachten 2147483647 ist der maximale Wert einer Ganzzahl auf meinem System. Mache ich etwas falsch, oder ist das ein Problem mit BigDecimal?

BigDecimal test = new BigDecimal("1e2147483647");

test.compareTo(new BigDecimal(0));  //Returns 1
test.compareTo(new BigDecimal("1e-2147483647"));  //Returns -1
test.intValue();  //Throws NegativeArraySizeException

  • stackoverflow.com/questions/17945985/…

    – kosa

    1. Juli 2015 um 19:58 Uhr

  • Danke, die Frage hatte ich nicht gesehen. Ich war nur überrascht, dass es keine NumberFormatException vom Konstruktor ausgelöst hat, wie dies bei einer um eine Ziffer größeren Zahl der Fall ist.

    – DJMatch3000

    1. Juli 2015 um 20:02 Uhr

  • Dies ist eher ein Vorschlag als ein Wissen, aber 1e-2147483647 ist eine ziemlich große Zahl. Um genau zu sein, log_2(10^2147483647) / 8 / 1024^3 = 0.83... sollte die minimale Größe (in Gigabyte) ergeben, um eine so große Zahl als Ganzzahl darzustellen. Vielleicht ist dies eine Art Speicherzuweisungsproblem?

    – Turing85

    1. Juli 2015 um 20:03 Uhr

  • @ DJMatch3000: Nein, Ihre Eingabe ist gültig und darstellbar, obwohl dies der maximale Exponent ist, den Sie darstellen können BigDecimal. Ihr Fehler ist legitim.

    – Louis Wassermann

    1. Juli 2015 um 20:05 Uhr

Benutzer-Avatar
Louis Wassermann

Nein, Sie scheinen einen legitimen Fehler zu haben. Der Fehler tritt in JDK7 auf, wurde jedoch in JDK8 behoben. Ihre Werte sind korrekt darstellbar als BigDecimals, und sollten sich korrekt verhalten, tun es aber nicht.

Durchsuchen den Quellcode von BigDecimalauf Zeile 2585, this.precision() ist 1, und this.scale ist -2147483647. this.precision() - this.scale daher überläuft, und der folgende Überlauf wird nicht korrekt behandelt.

Dieser Fehler wurde repariert im JDK8 von die Subtraktion durchführen long Arithmetik.

  • Funktioniert dies in Java von Android 17 (ähnlich wie JDK6)?

    – Ky.

    7. Juli 2015 um 13:10 Uhr


1205300cookie-checkJava BigDecimal Möglicher Überlauffehler

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy