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)

"Primitive Datentypen sind ebenfalls plattformunabhängig, weil sie stets im Big-Endian-Format gespeichert werden" ?

Auch wenn sie in Betriebssystem A in Big-Endian-Format und in Betriebssystem B in Little-Endian-Format gespeichert werden würden, würde das nichts an der Plattformunabhängigkeit ändern. Ich werde den Satz demnächst ändern, ausser jemand nennt mir einen Grund, warum dieser Satz doch stimmen sollte. Christoph May 19:08, 14. Okt. 2008 (CEST)

Vielleicht sollte man das besser als "weil sie stets wie im Big-Endian-Format behandelt werden" schreiben. Wie sie nun intern gespeichert werden ist doch völlig egal. Aus Sicht der Programmierers ist es jedenfalls immer Big-Endian. -- ▪Niabot▪議論▪ 21:47, 14. Okt. 2008 (CEST)

Genau, wie sie gespeichert werden ist völlig egal. Ich nehme den Satz mal eben raus. Ich sehe aber auch nicht ganz, an welcher Stelle sie denn für den Programmierer Big-Endian sein sollen. Bei der Endianness geht es doch nur um die Speicherung, dachte ich bisher immer. Christoph May 22:24, 14. Okt. 2008 (CEST)

Es geht hierbei um die Bitoperatoren und von welcher Seite quasi die Bits abgezählt werden. D.h. ob ich mit der Änderung der Bits 0 das Vorzeichen beeinflusse oder ob sich die aktuelle Zahl nur um 1 ändert ist schon ein Unterschied. Quasi macht sich die "Speicherung" doch bemerkbar. Nur eben, das die VM dem Programmierer immer ein System mit Big-Endian vorspielt, auch wenn es intern nicht der Fall ist. -- ▪Niabot▪議論▪ 22:41, 14. Okt. 2008 (CEST)

Es kann natürlich sein, dass es neben der Speicher-Endianness (meiner Meinung nach die übliche Verwendung) auch noch eine Bitoperations-Endianness gibt. Aber das führt dann über das Thema hier hinaus. Der Artikel ist jedenfalls jetzt an der Stelle, um die es hier geht, in Ordnung und ich lasse ihn jetzt so. Christoph May 11:01, 15. Okt. 2008 (CEST)

Nachtrag: Eine Stelle, an der die Endiness eine Rolle spielt, ist die Definition der Schnittstelle DataInput ([1]). Die ist aber nicht Teil der Sprachspezifikation. --j ?! 12:24, 15. Okt. 2008 (CEST)

Minimaler Speicherverbrauch

Ich lese gerade das ein Boolean 8Bit belegen soll und unter der Tabelle steht, das es der minimale Verbrauch sein soll. Für alle Datentypen scheint dies korrekt. Nur eben für Boolean nicht. Denn je nach Implementierung der VM könnte diese auch mehre Booleans in einem Byte unterbringen, da dann effektiv weniger als 8 Bit pro Boolean sind. -- ▪Niabot▪議論▪+/− 16:23, 9. Mär. 2009 (CET)

Hi. Die Tabelle habe ich am 31. August 2005 aus (Programmiersprache) übernommen. Ursprünglich stand dort mal „1 bit“, das wurde jedoch am 2. November 2004 von Messi entfernt, wohl weil die Java-Spezifikation hierzu keine Aussage macht. Am 2. November 2004 hat dann eine IP „8 bit“ dorthin geschrieben mit der Begründung „Anmerkung zur Größe, 8 Bit für Boolean“. Einen Beleg dafür hat die IP leider nicht geliefert. Ich frage mich jetzt, von welcher Größe wir eigentlich reden.

1. Die Sprachspezifikation sagt in Abschnitt 3.3.4, dass boolesche Werte als int verarbeitet werden (das wären dann 4 Byte).
2. In Abschnitt 3.6.1 steht, dass sie auf dem Stack den gleichen Speicherplatz belegen, wie byte, char, short, int oder float, also wohl ebenfalls 4 Byte.
3. In der Fußnote 2 steht, dass Arrays boolescher Variablen als Arrays von Bytes gespeichert werden, also mit 1 Byte pro boolean.
4. Interessant ist auch dieser Blog-Eintrag, demzufolge ein boolesches Attribut bis zu 8 Bytes konsumieren kann, weil die virtuelle Maschine nämlich immer 8 Byte auf einmal allokiert.

Fazit: Messi hatte wohl nicht ganz unrecht damit, die Größenangabe für boolesche Werte zu entfernen. --j ?! 15:41, 10. Mär. 2009 (CET)

Eingabe / Ausgabe

Hallo. Ich würde mich super freuen, wenn jemand einen ähnlichen Abschnitt wie den en:Java_Platform,_Standard_Edition#java.io hier einbauen könnte.

Eine Übersicht wäre da sehr schön, weil mich grad das ganze InputStreamReader und BufferedReader keyboard ein wenig verwirrt :S

Und überhaupt, wenn mal jemand Ahnung hat, könnte der Artikel zu allgemeinen Dingen ja ergänzt werden. Grüße --WissensDürster 17:15, 25. Mai 2009 (CEST)

Du bist im falschen Artikel. Hier geht es um die formale Syntax der Programmiersprache Java, nicht um deren Standardklassenbibliotheken. Vielleicht findest du ja in Java (Programmiersprache), was du suchst. --j ?! 22:20, 25. Mai 2009 (CEST)

Oh je, ich merke gerade, dass das alles schlecht miteinander verknüpft ist. Der Artikel, den du suchst, ist Java Platform, Standard Edition. --j ?! 22:22, 25. Mai 2009 (CEST)

Eigentlich sind mir die Bibliotheken egal. Es geht mir mehr um das Konzept was hinter diesem Stream-Zeug stehn soll. Ich habs bei C auch schon nicht verstanden. Unter en:Input/output und dem entsprechenden dt. Artikel findet man auch nichts brauchbares :/ ... --WissensDürster 17:29, 26. Mai 2009 (CEST)

Tja, dann gibt es da noch Datenstrom. Vielleicht liefert der den theoretischen Hintergrund, der dir fehlt? --j ?! 21:34, 26. Mai 2009 (CEST)

Naja, muss mal sehn was ich da zusammenklauben kann. Es fehlt ne Verbindung von Datenstrom und die (allgemeine) Realisierung in Programmiersprachen. Oder so Fragen wie "Was ist alles eine Ein- oder Ausgabe"? Wieso gibt es für in/out immer so komplizierte Stream-Ausdrücke, wenn am Ende eh immer Tastatur/Bildschirm gemeint sind. (Ich hab da mal gefragt, es ist nahezu unmöglich in (normalen/allg.) Programmiersprachen neue I/O-Geräte zu implementieren. Alles irgendwie Schnittstellen-Zeugs. ) Manchmal werden Arrays und sequenzieller Zugriff erwähnt, erklärt aber nirgends. Im Dabei bleibt I/O eigt. das schwerste an einer P-Sprache.

Vllt. ist es aber auch alles egal und nur mein persönliches Problem. Meine Meinung, dass irgendwo irgendwas fehlt, hilft natürlich nicht viel weiter. Sryy --WissensDürster 14:22, 27. Mai 2009 (CEST)

Das mit den Streams ist eigentlich trivial. Stell dir einfach eine Funktion zu Ausgabe vor. z.B. public void write(byte[] b) Diese Funktion schreibt einfach ein byte-Array. Wie das genau gemacht wird, das hängt vom Stream-Objekt und dem Unterbau der VM ab. So rufen die meisten solchen Funktion z.B. von FileOutputStream hier native, in C geschriebene Funktionen auf, die mit Streams im engeren Sinne nichts mehr zu tun haben.

Wozu dann aber diese Streamgeschichte? Ganz einfach gesprochen ist es mit Hilfe der Objektorientierung möglich Stream-Objekte ineinander zu verschachteln. So besitzt ein BufferedOutputStream beispielsweise ein "Child", an das er seine Daten beim schreiben weiterreicht. Technisch passiert das trivial so, das der BufferedOutputStream die Bytes erst einmal in ein Array schreibt. Ist dieses voll, dann ruft er die Funktion "write(byte[] b)" des untergeordneten Streams auf und leert seinen Cache (das Array).

PS: Lies dir dazu am besten einmal die Dokumentation von FilterInputStream durch und schau dir am besten einfach mal den Quelltext dieser Klasse an. Dann siehst du, dass ein Stream pro IO-Funktionsaufruf nichts weiter macht, als die Daten an einen anderen Stream weiterzureichen. Mehr auch nicht... (Alles einfacher als man denkt) -- ▪Niabot▪議論▪+/− 17:35, 27. Mai 2009 (CEST)