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 Bearbeiten

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)Beantworten

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

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

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)Beantworten

Minimaler Speicherverbrauch Bearbeiten

Ich lese gerade dass 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)Beantworten

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)Beantworten
Ich schlage vor diesen Interessanten Stand auch in der Tabelle wieder zu spiegeln. Wie es denn jetzt auch sei, der bisherige Wert von "1 bit" ist sicher nicht in allen Fällen wahr. Ich habe die Tabelle auch dementsprechend angepasst --max (nicht signierter Beitrag von 95.208.68.114 (Diskussion) 22:11, 22. Jan. 2011 (CET)) Beantworten

Eingabe / Ausgabe Bearbeiten

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)Beantworten

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)Beantworten
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)Beantworten

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)Beantworten

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

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)Beantworten

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)Beantworten

Feld Bearbeiten

Im Artikel steht: 'Bei einem eindimensionalen Feldes muss der Datentyp beim Erstellen ein Integer (int) sein.'

Ist das wirklich so? Ist also ein Feld von double's ist nicht möglich?

Z.B. double[] x = new double[10]; ?

Bzw. welches Argument hat nochmal die static Methode main() in Java?

Zu der länglichen Analogie mit dem Damenbrett: Muss das sein? Wenn ein Leser wirklich nicht das Konzept einer Tabelle bzw. einer Matrix kennt, kann er das ja in den entsprechenden Artikeln nachlesen.

Desweiteren sind die Code-Beispiele überkommentiert. Das lenkt 1. den Leser vom Wesentlichen ab und 2. passen die Zeilen nicht mehr in moderate Browser-Fenster-Breiten.

Das eine Anweisung mit 'print' bzw. 'length' im Namen etwas ausgibt bzw. die Länge ermittelt, ist doch klar. Auch Kommentare wie 'Die Matrix hat drei Zeilen und drei Spalten' passen besser in einen erklärenden Fliesstext-Abschnitt unter (oder auch über) das Code-Beispiel - falls diese Erklärungen überhaupt notwendig sind.

--Gms 10:46, 11. Dez. 2009 (CET)Beantworten

Der Abschnitt, wie du vllt. nicht weist, grad erst hier integriert - nach LA auf eigenständigen Artikel. An den Kommentaren kannst du gerne selber verbessern. Ich wüsste nich wieso das mit double nicht gehn sollte - hab aber auch nur vor einiger Zeit nen Anfängerkurs gemacht...
PS: Wenn sich irgendwelche Erkenntnisse zur Mainmethode ansammeln, bitte hier Methode_(Programmierung)#.E2.80.9Emain.E2.80.9C-Methode_in_Java auch ergänzen. Da wäre ich euch sehr verbunden. Danke --WissensDürster 17:42, 11. Dez. 2009 (CET)Beantworten
Hab nochmal gesucht (und auch gleich ein bißchen im Artikel rumgefixxt): http://www-ti.informatik.tu-cottbus.de/Studium/06ZgEinfProg/Skript/P9.pdf da steht auch explizit, dass es nur positive Ganzzahlen sein dürfen ... eine Erklärung kann ich dir nun nicht liefern, aber wird wohl so sein. Anders, wenn ich nicht so faul wäre, könnte man ja auch in 2 Minuten einfach mal was compilieren, Eclipse oder so hätte dir wohl ne genaue Fehlermeldung geliefert. ^^ Bei solchen Fragen ist meine Erfahrung, nie Antworten in der Literatur suchen - selber probieren! Grüße --WissensDürster 17:59, 11. Dez. 2009 (CET)Beantworten
Die derzeitige Aussage im Artikel „muss der Datentyp beim Erstellen ein Integer (int) sein“ ist definitiv falsch. Außerdem ist „beim Erstellen“ unglücklich ausgedrückt, da in der Codezeile oberhalb Deklaration und Objekterzeugung(/-erstellung) angeführt werden, der Typ einer Variable aber schon bei der Deklaration festgelegt wird.
Wenn du das Skriptum genau betrachtest steht dort „Wobei Anzahl ein konstanter positiver Ganzzahl-Ausdruck sein muss.“, d.h. die Dimension, die Größe des Arrays muss – natürlich – positiv und ganzzahlig sein (weil Null sinnlos wäre, da ich dann nichts in dem Feld speichern könnte, und negativ ebenso, da das kein Konto ist, wo ich eine Schuld eingehen kann).
Erwähnenswert ist auch noch, dass, im Gegensatz zu anderen Sprachen, mehrdimensionale Felder als Felder von Feldern gebildet werden. Syntax [m][n][...] im Gegensatz zu [m,n,...]. [Nachtrag: Steht schon weiter oben. --Geri 23:23, 11. Dez. 2009 (CET)]Beantworten
Selber probieren ist zwar gut für den Lernerfolg, fällt aber hier in der WP unter WP:NOR. Und was dann zeitweise dabei rauskommt... --Geri 19:22, 11. Dez. 2009 (CET)Beantworten
Das ist nur falsch ausgedrückt. Mit dem "int" ist die Länge des Feldes, also die Anzahl der Plätze für Array-Einträge gemeint. Im Beispiel wäre es ein Array mit 10 (int) Plätzen für double-Werte. D.h. ein Array kann nur mit integern indiziert werden. Daraus folgt das ein maximale Länge von 231 − 1 haben kann. D.h. bei Datentyp byte wäre so nur eine Menge von 2 GB adressierbar. --   19:40, 11. Dez. 2009 (CET)Beantworten
Na, „nur“ falsch ausgedrückt ist doch auch falsch, nicht? ;-) Wenn dort steht „muss der Datentyp“, dann bezieht sich das eben auf den Datentyp, nicht die Anzahl. --Geri 22:48, 11. Dez. 2009 (CET)Beantworten
@Geri Das Anlegen von Arrays mit der Länge "0" ist durchaus möglich und auch sinnvoll. So wird z.B. bei der Auflistung des Inhalts eines leeren Verzeichnisses ein Array mit Länge 0 zurückgegeben. --   19:48, 11. Dez. 2009 (CET)Beantworten
Ja, da hast du natürlich recht. Rein formal ist auch eine negative Dimension möglich, wirft dann allerdings zur Laufzeit eine NegativeArraySizeException. So tief wollte ich aber in diesem „groben Überblick“sartikel nicht gehen. --Geri 22:48, 11. Dez. 2009 (CET)Beantworten
Das meinte ich eigentlich nicht. Ich meinte das man Arrays mit der Länge "0" anlegen kann. Diese enthalten dann zwar nicht ein Element, werden aber immer mal wieder gebraucht, auch wenn sie natürlich für sich gesehen Unsinn sind ;-) --   00:23, 12. Dez. 2009 (CET)Beantworten
PS: Ich bin über den Abschnitt mal drüber gegangen und habe zumindest bis zu den mehrdimensionalen Arrays mal gründlich geputzt. ;-) --   00:24, 12. Dez. 2009 (CET)Beantworten
Der Aufrufparameter von main() ist "String args[]", kann aber auch "String[] args","String[] trololo" oder "String trololo[]" heißen. args steht für "Argument String" Das ist ach der Aufrufparameter, das heißt, dass wenn du in die Konsole schreibst "java Test A B C" dann entspricht args diesem Wert: "new String[]{"A","B","C"}" also ein String-Array mit den Werten "A","B" und "C".178.200.20.88 17:40, 9. Jul. 2012 (CEST)Beantworten

Array versus Feld versus Attribut Bearbeiten

Die deutsche Bezeichnung „Feld“ für Array finde ich etwas unglücklich, weil sie offensichtlich dazu zwingt, die Fields als „Attribute“ zu bezeichnen um Verwechslungen zu vermeiden. „Attribut“ ist aber ein Begriff, der in der Java-Sprachspezifikation (die nur auf englisch vorliegt) überhaupt nicht vorkommt. Dort steht beispielsweise, dass die „Variablen einer Klasse“ Field genannt werden (deutsch „Feld“).[2] --j ?! 21:07, 13. Dez. 2009 (CET)Beantworten

Ja das finde ich auch etwas unglücklich. Schließlich haben wir in Java, auch vom üblichen Sprachgebrauchen, folgende Dinge:
  • Klassen (Classes)
  • Abstrakte Klassen (Abstract Classes)
  • Schnittstellen (Interfaces)
  • Instanzen (Instances)
  • Methoden (Methods)
  • Parameter (...)
  • Variablen (Fields, Class Members)
  • Felder (Arrays)
  • Ausnahmen (Exceptions)
  • ...
Vielleicht sollte man sich hier mal auf eine eindeutige Benennung einigen. --   21:24, 13. Dez. 2009 (CET)Beantworten
Vielleicht sollte man das an den Anfang schreiben, dass es "hier und sonst wo" günstig wäre, mit einer sprache konsistent zu arbeiten und dann für welche man sich im folgenden entschieden hat =) Was Sprichst gegen die bewerte Methode stets deutsch, aber bei Einführung eines neuen Begriffes einmal in Klammern Englisch?! --WissensDürster 22:09, 13. Dez. 2009 (CET)Beantworten
Zum Beispiel die Tatsache, das auch im deutschen Sprachgebrauch von Arrays die Rede ist wenn Arrays gemeint sind? [3] Den Begriff „Feld“ für Array habe ich vor der Wikipedia noch niemals gehört, auch nicht in meinem mittlerweile schon recht lange zurückliegenden Studium. --j ?! 21:40, 14. Dez. 2009 (CET)Beantworten
Tatsächlich ist das bei Array/Feld eine ziemlich verbreitete Ausnahme ... "Feld" ist einfach zu zu vielem Homonymie... also bei allem sonst, wie beschrieben und für "Array" andersrum. (Das du davon aber generell nichts gehört hast, find ich schon etwas komisch [hättest ja auch eigenständig ein Wörterbuch bemühen können ; ) ]). Grüße --WissensDürster 22:54, 14. Dez. 2009 (CET)Beantworten
Der dt. Artikel heißt aber auch: Feld (Datentyp), den hast du noch nie gesehen? ; ) --WissensDürster 20:15, 15. Dez. 2009 (CET) Beantworten
Das mag sein. Jedoch ist mir in Java überall der Begriff Array gebräuchlicher. Die anderen Begriffe variieren je nach Autor etwas. Jedoch verwenden fast alle die Bezeichnung Array. Vermutlich auch um mit der Bezeichnung "Fields" nicht in Konflikt zu geraten. Feld selbst ist eigentlich zu allgemein, da es nur einen Bereich im Speicher bezeichnet, der in manchen Sprachen nicht mal fest typisiert ist oder sein muss. --   20:44, 15. Dez. 2009 (CET) PS: Wir haben auch den Artikel Assoziatives Array ;-) --   20:46, 15. Dez. 2009 (CET)Beantworten
Wir wollen ja keine neue einheitliche Wahrheit erschaffen. Und ich werd hier auch nichts editieren, da ihr die Profis seid. Es war einfach nur der Hinweis, dass man diese Sprach-Begriffs-Überschneidungen kurz erwähnen sollte. --WissensDürster 20:48, 15. Dez. 2009 (CET)Beantworten
Sie auch weiter unten. Irgendwie fehlt wirklich ein Absatz der klarstellt, welche Bezeichnungen im Artikel verwendet werden und was sie bedeuten. --   21:22, 15. Dez. 2009 (CET)Beantworten

Klammern bei den Kontrollstrukturen Bearbeiten

Die geschweiften Klammern sind streng genommen nicht Bestandteil der Kontrollstrukturen. Denn schließlich können Schleifen (for, while, do while) und bedingte Verzweigungen (if, if else, else) auch ohne Klammern geschrieben werden. Die geschweiften Klammern gehören zu einer Blockanweisung, also einer Gruppierung von Einzelanweisungen, die überall auftreten kann. Beispiel:

    int a = 7;
    {
        int b = 20;
        int c = b - a;
    }

Genauso verhält es sich auch bei den Kontrollstrukturen. Diese verstehen nur eine einzelne Anweisung oder einen Block als Bestandteil. Da üblicherweise mehrere Anweisungen innerhalb einer Schleife durchgeführt werden sollen, verwendet man hier einen Block, was dann diese geschweiften Klammern ergibt. --   16:10, 14. Dez. 2009 (CET)Beantworten

korrekt. ich hab den abschnitt kontrollstrukturen mal entsprechend um ein paar klammern gekürzt. -- 16:15, 14. Dez. 2009 (CET)Beantworten

Ausdruck Bearbeiten

Mir fällt es gerade schwer mit exakten Begriffen zu arbeiten. Sollte man vielleicht am Anfang des Artikels einige Bezeichnungen definieren? Dazu fallen mir gerade folgende Bezeichnungen ein:

Ausdruck (Expression)
Eine beliebige korrekte Syntax, die am nach der Auswertung einen Wert ergibt.
Das trivialste Beispiel wäre wohl schon das Schlüsselwort "true" oder eine Zahl ("1").
Anweisung (Statement)
Sie kann sich aus mehreren Ausdrücken zusammensetzen die mit einander verkettet werden und wird am Ende mit einen Semikolon abgeschlossen.
Anweisungsblock (Statement block)

Ich würde das irgendwie sinnvoll finden, wenn dies am Anfang des Artikels für den Leser geklärt werden könnte. --   21:20, 15. Dez. 2009 (CET)Beantworten

Dass ich das auch sinnvoll fände, steht ja schon weiter oben ;) --WissensDürster 21:53, 15. Dez. 2009 (CET) Beantworten
Ich halte das nicht für sinnvoll. Diese Konstrukte sind nicht spezifisch für Java, sondern kommen in jeder höheren Programmiersprache vor die mir jetzt spontan einfällt. Verlinkung zu den jeweiligen Artikeln (so vorhanden, hab' jetzt nicht nachgesehen) sollte reichen.
BTW. Nicht jede Anweisung wird mit einem Strichpunkt abgeschlossen – Kontrollstrukturen beispielsweise. --Geri 07:39, 27. Dez. 2009 (CET)Beantworten
Das mag nicht auf jeden verwendeten Begriff zutreffen, denn die Bedeutung des jeweiligen Begriffs unterscheidet sich doch immer wieder im Detail innerhalb jeder Programmiersprache. Deshalb habe ich jetzt auf den allgemeinen Begriff/Artikel dazu verlinkt. Zudem soll diese Darstellung darüber aufklären, das es eben verschiedene Bezeichnungen für ein und den selben Term gibt, die sich in der Literatur munter abwechseln und welche Bezeichnung innerhalb des Artikels verwendet wird oder werden sollte; damit nicht jeder in jedem Absatz eine andere Bezeichnung verwendet und damit den Leser verwirrt. Ein Beispiel dafür sind die Felder, die allgemein als "Array" bezeichnet werden. So sollte dies auch im Artikel der Fall sein und man sollte entweder nur von Feldern (nicht zu verwechseln mit fields) oder Arrays geschrieben werden. --   10:43, 27. Dez. 2009 (CET)Beantworten

Titel des Artikels Bearbeiten

Hallo,

ich halte den Titel des Artikels, "Java-Syntax", für unglücklich gewählt. Im Inhalt wird dann doch für jedes Sprachkonstrukt die Semantik mit beschrieben. Für Leute, die den Unterschied zwischen Syntax und Semantik noch nicht kennen und verstehen wollen, ist das nur verwirrend. -- 132.231.132.68 17:24, 18. Jan. 2010 (CET)Beantworten

Zurgiffsmodifikatoren Bearbeiten

Ich finde die Überschriften der Zugriffsmodikfikatoren im englischen Wiki (http://en.wikipedia.org/wiki/Java_syntax#Access_modifiers) sehr viel übersichtlicher und weniger verwirrend.

Vielleicht mal in die Richtung ändern? --Schattenkrieger 13:30, 15. Jan. 2012 (CET)Beantworten

Gute Idee --Sebastian.Dietrich 23:13, 15. Jan. 2012 (CET)Beantworten

"Die Größe eines Arrays ist fix und kann nach der Instanzierung nicht mehr geändert werden." Falsch. Bearbeiten

Das stimmt so nicht, man kann die Größe zwar nicht mehr direkt verändern, man kann aber das Array neu initialisieren mit unterschiedlicher Länge aber gleichen Inhalten.

public static int[] lengthen(int[] A,int B){

	int[] O=new int[B];
	for(int i=0;i<A.length&&i<B)O[i]=A[i];
	return(O);

}

also:

int[] A={1,2,3}; // Jetzt hat A die Werte 1,2,3 und somit die Länge 3.
A=lengthen(A,4)  // Jetzt hat A die Werte 1,2,3,null und somit die Länge 4.

178.200.20.88 18:05, 9. Jul. 2012 (CEST)Beantworten

In deinem Beispiel ist A kein Array, sondern eine Variable. Sie enthält erst eine Array-Referenz, und später eine andere. --Daniel5Ko (Diskussion) 18:38, 9. Jul. 2012 (CEST)Beantworten
Sensation: Man kann in Java sogar Zahlen ändern.
int x = 0; x = 1;
Jetzt ist die 0 auf einmal eine 1. Man kann zwar 0 nicht mehr direkt ändern, aber man muss nur x einen neuen Wert geben und am Ende ist x immer noch ein int. Noch besser der Negationsoperator:
boolean p = true; p = !p;
Er beweist, dass es keine absolute Wahrheit gibt. Ich bin mir aber nicht sicher, ob deine Behauptung stimmt, denn dein Code compiliert irgendwie nicht. --Zahnradzacken (Diskussion) 19:45, 9. Jul. 2012 (CEST)Beantworten
Nein, man kann die Größe eines Arrays nach der Erzeugung nicht mehr verändern. Das steht in der Java-Spezifikation auch sehr eindeutig, ich weiß aber grad nicht mehr wo. Du erzeugst doch ein neues Object vom Typ Array indem du
new
verwendest. Der alte Array wird für immer die gleiche Größe haben. Divof (Diskussion) 12:41, 2. Apr. 2017 (CEST)Beantworten

Kommentare Bearbeiten

Ich habe den Einleitungstext zu den Kommentaren gelöscht und durch einen kurzen Erläuterungssatz ersetzt. Versehentlich ist der Bearbeitungskommentar abgehackt worden, deshalb hier die Begründung:

  • Die detailierte Erläuterung eines Konzepts gehört nicht in einen Artikel über Syntax.
  • Die dargelegte Meinung zu Kommentaren ist eindeutig POV; die Clean-Code-Philosophie besagt z.B. etwas ganz anderes.

--Zumbo (Diskussion) 16:34, 11. Okt. 2013 (CEST)Beantworten

Da hast du natürlich 100% recht. Schon Martin Fowler meinte in Refactoring das Kommentare ein Code Smell sind. --Sebastian.Dietrich 18:33, 11. Okt. 2013 (CEST)Beantworten

Defekter Weblink Bearbeiten

GiftBot (Diskussion) 17:00, 22. Dez. 2015 (CET)Beantworten