Diskussion:Java-Syntax

Ich habe den Satz

Im Gegensatz zu einigen älteren Programmiersprachen, wie beispielsweise C, ist die Reihenfolge der Auswertung von Ausdrücken in Java bereits in der Sprachdefinition festgelegt.

in

Im Gegensatz beispielsweise zur Programmiersprache C ist die Reihenfolge der Auswertung von Ausdrücken in Java bereits in der Sprachdefinition festgelegt.

geändert.

Die erste Formulierung schien mir zu suggerieren, dass die Festlegung der Auswertungsreihenfolge ein besonders modernes Sprachmerkmal sei bzw. dass in C die Auswertungsreihenfolge aus Unachtsamkeit oder Unkenntnis der Sprachentwickler nicht festgelegt wurde. In C wird die Auswertungsreihenfolge aber absichtlich nicht im Standard festgelegt, um dem Compiler zusätzliche Optimierungsmöglichkeiten zu eröffnen. --Tobias Bergemann 09:26, 25. Okt 2005 (CEST)

Gleitkommazahlen und IEEE 754-Standard

Darauf, dass die Java-Typen float und double den IEEE 754-Standard nicht einhalten, hat William Kahan in verschiedenen Artikeln schon vor einiger Zeit hingewiesen; sobald ich dazu komme, gebe ich die genaue Quelle an. — Nol Aders 02:38, 27. Okt 2005 (CEST)

Welcher Teil des Standards wird nicht eingehalten? Wo ist die Abweichung? Ohne diese Angaben ist der Hinweis sinnlos. Daher habe ich ihn erstmal wieder entfernt. Ich würde mich aber freuen, wenn du ihn – diesmal vollständig – wieder einträgst. (Und lass bitte das Wörtchen „leider“ weg, das drückt eine Meinung aus.) --jpp ?! 12:50, 27. Okt 2005 (CEST)

Jetzt hast du den Text wieder eingebaut und das ist auch gut so. Aber zufrieden bin ich damit leider immer noch nicht. Und zwar aus folgenden Gründen:

1. Das „Vorsicht!“ halte ich für stilistisch unangemessen.
2. Aus dem Text erfahre ich immer noch nicht, was genau bei Über- und Unterlauf und bei der Behandlung von NaN falsch ist. Das lässt sich doch sicher in zwei bis drei Sätzen prägnant darstellen, oder?
3. Der Weblink gehört nicht in den Text, sondern unter Weblinks. So ist das nix.

Nimm das aber jetzt bitte als konstruktive Kritik auf. Ich bin wirklich an diesen Informationen interessiert und auch der Meinung, dass sie im Text stehen sollten, nur halt in anderer Form. Sorry, wenn ich gerade sehr pingelig klinge, ist nicht böse gemeint, aber so bin ich halt. ;-) --jpp ?! 21:17, 27. Okt 2005 (CEST)

Ich sehe, du hast noch etwas ergänzt. Ich habe es noch etwas umarrangiert, z. B. den Weblink ans Ende des Artikels gestellt. Die von dir genannte Quelle stammt von 1998. Weißt du zufällig, wie weit deren Aussagen auch noch in den aktuelleren Java-Versionen gelten? Z. B. wurde mit Java 1.3 das neue Schlüsselwort „strictfp“ eingeführt. --jpp ?! 15:27, 31. Okt 2005 (CET)

Wenn ich es richtig erinnere, behebt das neue Schlüsselwort „strictfp“ die Probleme, auf die Kahan 1998 hingewiesen hat, nicht; ich gehe dem aber nach, sobald ich dazu komme.

Ich hänge nicht an dem "Vorsicht!", ich denke aber, dass wir unbedingt darauf hinweisen sollten, dass der IEEE 754-Standard eben nicht ganz eingehalten wird; wenn jemand sich dann darauf verlassen wollte, muss er halt selbst in den Quellen forschen, solange wir die Zusammenfassung hier noch nicht drin haben ... — Nol Aders 21:33, 1. Nov 2005 (CET)

Der Vorwurf des Nichteinhaltens ist unsinnig, da es keine anderen Sprachen gibt, die IEEE 754 vollständig unterstützen. Kahan schrieb den Artikel 1998 (!) zusammen mit Darcy (der eine Art numerisches Java, "Borneo", konzipierte), in der Hoffnung, dass die damals junge Sprache Java im Gegensatz (!) zu den anderen Sprachen vielleicht doch noch IEEE 754 vollständig umsetzt. Diese Hoffnung wurde nicht nur enttäuscht, auch in den anderen Sprachen wird IEEE 754 immer mehr kastriert. C unterstützte Zugriff auf Flags und Trapping nie, C99 warf das Konzept endgültig auf den Haufen (wenn es auch beschönigend als "nicht unterstützt" deklariert wird). Weder Fortran, C, Java noch irgendeine andere Sprache bietet die von IEEE 754 als notwendig deklarierten Features. Der erweiterte Datentyp Single wurde noch nie benutzt, der erweiterte Datentyp double (der identisch ist mit dem Coprozessor Format von Intel = 80bit) wurde nur in wenigen Compilern unterstützt. sNaNs wurden durch qNaNs ersetzt, es gibt keinen Zugriff auf die Flags INVALID, OVERFLOW, INEXACT usw. Man muss den Artikel dementsprechend nicht als "Nur Java ist böse" sehen, sondern als Versuch, Java im Gegensatz zu anderen Sprachen numerisch zu retten. --136.172.253.11 19:09, 18. Sep. 2008 (CEST)