maettig.com

Thiemos Archiv

Ich hasse Java. [Disclaimer: Das war 2003, als Java 1.4 aktuell war. Jahre später ist Java zu einer meiner Lieblingssprachen geworden, gleich nach C#.] Hab' ich das schon mal gesagt? Ich meine, wozu habe ich eigentlich eine der angeblich fortschrittlichsten Programmiersprachen, wenn ich dann doch jeden Mist allein machen muss?
Beispiel 1: if (variable == "String") ist falsch. Eine Fehlermeldung gibt's aber auch nicht. Nein, weit gefehlt. Java vergleicht statt dessen die Speicheradressen der beiden Strings. Das ist immer false. Hallo!? Was soll das? Wieso kann == nicht einfach das machen, was ich andauernd brauche, und .equals() vergleicht die Adressen (sofern das jemals irgend jemand brauchen sollte, was ich mir nicht vorstellen kann)? [Update: An dieser Meinung hat sich nichts geändert, auch wenn ich heute natürlich damit umzugehen weiß. C# zeigt, wie es sein sollte.]
Beispiel 2: switch (variable) { case "String": ... geht natürlich auch nicht. Bei switch sind nur Zahlen erlaubt. Na toll. Wozu gibt's das überhaupt, wenn man dann doch ständig if benutzen muss? [Update: Ab Java 7 ist das endlich möglich.]
Beispiel 3: if (variable.equals("String")) löst eine NullPointerException aus. Zum zweimillionsten Mal. Weil die Variable null enthält. Na und? Wieso kann .equals() dann nicht einfach false zurück liefern? Ist das zuviel verlangt? [Update: null und alles, was dazu gehört, betrachte ich inzwischen als wichtiges sprachliches Mittel.]
Beispiel 4: variable.replace("<", "&lt;") geht nicht. Die Methode .replace() existiert nur für einzelne Zeichen. Aha. Toll. In welchem Jahr leben wir? 1982? Soll ich jetzt wegen jeder primitiven Stringersetzung .replaceAll(regex, replacement) bemühen? [Update: Seit Java 1.5 gibt es die Methode auch für Zeichenketten.]
Beispiel 5: Es gibt ein Äquivalent für urlencode(), aber keines für htmlspecialchars(). Wieso nicht?
Das ließe sich endlos fortsetzen ...
Heul doch. ;) Aber gut, ich könnte auch von nervigen Einschränkungen anderer Sprachen berichten, zumal Fall 2 eigentlich noch nie mit Strings ging, auch in Delphi oder C nicht. Apropos, Delphi (zumindest Version 5 von '99) mag auch keine Mengenoperationen mit mehr als 256 Elementen, will keine Standardwerte für eine an eine Funktion oder Prozedur übergebene Records zulassen, das Exception-Handling kann man in der Laufzeitumgebung auch nicht "ruhig" stellen (oder ich hab' nie rausgefunden wie das geht) etc. Aber sowas wie in Beispiel 1 ist schon ziemlich krass.
tom
1. String is nen Objekt, also ist == false sonnenklar bei unterschiedlichen Objekten. 2. switch war schon immer nur für Konstanten gedacht, ob nun Java oder C. 3. wenn irgendwas null ist, ist es klar, dass ne Exception ausgelöst wird. Übrigens: "String".equals(variable) funktioniert immer. 4. Entweder nutzt du replaceFirst() oder replaceAll(). Also kein Beinbruch. 5. Keine Ahnung.
Ralf
1. Ich wusste, dass das als Antwort kommt, aber das lasse ich nicht gelten. Gibt es irgend einen gebräuchlichen Fall, zwei Objekte mit == zu vergleichen? Nein. Also warum steckt nicht die Funktion, die man ständig braucht, in ==, und der Objektvergleich z.B. in .indetical()? Weil's in Java keine Operatorüberladung gibt? ... 2. Hängt direkt mit Fall 1 zusammen. Mir leuchtet einfach nicht ein, dass es niemand für nötig erachtete, switch auch für Objekte zu definieren. Das könnte intern einfach auf .equals() gemapt werden. 3. So geht's. Danke! Der Groschen ist gefallen. Trotzdem. Wieso ist für null kein .equals() vordefiniert? null.toString() gibts doch auch. 4. replaceAll() ist mit Kanonen auf Spatzen geschossen. Außerdem muss ich dabei auf eventuelle Sonderzeichen achten. Ich will aber nur Strings ersetzen. ... 6. null.toString() liefert "null" zurück. Was soll ich damit anfangen? Wieso kann das nicht einfach ein leerer String sein?
Thiemo
1. Sicher gibt es den. Wenn du ne GUI hast mit mehreren Textfeldern, dann sollte dein Controller schon rausfinden können, welches Textfeld nen Ereignis ausgelöst hat. Also ==. Zweites Beispiel. Wenn du nen Objekt klonst, dann sollte equals() true liefern, == aber nicht, da es ein anderes Objekt ist. 2. switch is nur für Konstanten. wenn du int x; hast , kannst du kein switch machen, in dem es berücksichtigt wird. Hast aber recht, wär schön, wenn es sowas gäbe. 3. Wenn irgendwas null ist, kannst du keine Methode aufrufen, da das Objekt ja garnicht existiert. null.toString() gibt es nicht, kann es einfach nicht geben. 4. Zum Ersetzen würd ich lieber nen StringBuffer nehmen, musst zwar ne Methode selbst schreiben, aber dafür ist sie viel performanter. 6. Geht nicht, gibts nicht. Wenn irgendwas null ist, wird null geliefert. Wenn du über System.out.println(null); dir was ausgeben lässt, ist es klar und sinnvoll, dass "null" kommt, denn sonst findest du deine Fehler durch solche Statements nie. (Ist der String jetzt leer oder war er doch null?)
Ralf
Jetzt bin ich verwirrt. Mein JDeveloper behauptet, es gäbe null.toString(), aber dann ist's - natürlich - nicht kompilierbar. Getestet hatte ich besagtes System.out.println(null). Und da ist - meiner Ansicht nach - die Ausgabe "null" genauso willkürlich wie die Ausgabe eines leeren Strings. (Ist der String jetzt "null" oder war er doch null?) Nun, dir auf jeden Fall vielen lieben Dank dafür, dass du auf mein Austoben hier reagierst. :-)
Thiemo
Also ich nutz eclipse und bin hellauf begeistert. Dort zeigts mir an, dass null.toString() nicht geht. null ist ein primitiver Typ und kein Objekt. Übrigens, wenn du in toString() mal schaust, siehst du, dass dort intern ne statische Methode valueOf() ausgeführt wird, deswegen klappt System.out.println(null) auch. valueOf() vergleicht auf null und wenn ja, gibt es den String "null" aus. Das ist beim Debugging (in nem Debugger) nützlich, da du so immer siehst, ob was null ist oder den String "null" hat. Macht sich einfach besser, wenn man bei ner NullPointerException nachschaut, was jetzt null ist bzw. warum es null ist.
Ralf

Kommentare zu diesem Beitrag können per E-Mail an den Autor gesandt werden.

[ ← Zurück zur Übersicht ]

Impressum & Datenschutz