Startseite
> Java > Java sucks…
Java sucks…
Ich bin mit mein Java Projekt jetzt fast fertig, wobei ich erst am 23. Januar angefangen habe… Es ist extrem OOP-lastig geworden… Ich habe über 50 Klassen; der längste ist 18 Seiten lang, ca. 1000 Zeilen. Die Hauptvoraussetzung war die strikte Trennung zwischen Grafik und Logik. So musste ich vieles über Events lösen… Und Java Events sind… Komplett fürn Arsch…
Aber bevor ich mich über Java auslasse… Ein Vorschau auf mein Projekt… Ich werde später den Code zum Download hier verlinken…
Die KI hat noch ein paar Bugs… Und es ist auch selten dämlich… Noch!… Aber ich habe ja noch bis 25. Februar zeit. Für das Hauptmenü werde ich mir noch was künstlerisches einfallen lassen. Zur Zeit sieht es ziemlich karg aus.
Und hier die Klassen…
Nun zu Java…
Java sucks weil…
-
Keine unsigned Datentypen – Vor allem das umwandeln von Long in Hex machte es mir viele Probleme, wenn man die magische Grenze eines signed übertritt… Da wird der Wert nämlich negativ und Java behandelt den Wert auch als Negativwert…
-
Zwang zur Nutzung von Anonymen Klassen – Mein Code ist damit so was von “dreckig”… Ich habe dann immer das Bedürfnis duschen zu müssen, wenn ich den Code sehe. /* Edit */ Hauptsächlich im Zusammenhang mit Listener gemeint
-
@Override hat gar kein Nutzen – Ob ich es jetzt weglasse oder mit dranschreibe… Keinen Unterschied… Nichts…
-
Getter Setter vollkommen Käse – Das man Methoden nutzt um “Properties” Werte zuzuweisen, kann ich in C++ vorkommen verstehen… Aber in Java? WTF! Warum? Java möchte Modern sein, aber das ist absolut nicht modern. Meine Klassen ist gegen Ende vollkommen mit den Getter/Setter Methoden gepflastert… Vollkommen unübersichtlich… Tuet mir leid das sagen zu müssen… Visual Basic <= 6.0 ist eine “unfertige” unschöne (milde ausgedrückt) Sprache, aber VB hatte schon richtige Properties… Im Gegensatz zu Java… Ich konnte Property Zuweisungen in einer Zeile schreiben… Mein Code war übersichtlicher.
-
Das Threading ist lächerlich beschränkt – Ich wollte ein Thread für eine unbestimmte Zeit anhalten, aber sehe da: suspend() ist Deprecated. Ich konsultierte Google und nichts… Wenn man in Java ein Thread anhalten möchte, geht es nicht… Man muss den kompletten Thread beenden. Ist das nicht schön?Edit … Es funktioniert mit wait() und notify() – danke upeuker -
abstract methods in Nicht-Abstrakte Klassen – Geht nicht
-
Extension von Klassen – geht nicht… Ich muss eine Klassen immer erben um es erweitern zu können…
-
Überladen von Operatoren – geht nicht … und ich wollte so gern Child-Nodes durch den plus Operator hinzufügen
-
Indexer – gibt es nicht… Ok… Das ist vielleicht zu viel verlangt…
-
Mehrere Klassen in einer Datei – geht nicht
-
Primitive Datentypen – Ein schlimmes übel. Folgendes ist absolut nicht möglich: intData.toString() … Man muss entweder so: Integer.toString(intData) oder es so: Integer intData2 = intData; intData2.toString(); … Das ist gar nicht OOP… Mich wundert es aber wieso ich Primitive zu einem Object zuweisen kann oder warum der ++ Operator beim int Überladen ist… Compiler-trick vielleicht?
-
Trennung zwischen Code und GUI – Nicht gelungen… bzw. nicht vorhanden…
-
Events/Listeners – Die schlimmste Ausgeburt der Hölle… So etwas dumm komplexes und unübersichtliches habe ich echt noch nie gesehen. Frage: Warum ist dieser Dreck nur mit Interfaces gelöst worden? Ich muss deswegen Methoden implementieren, dass ich absolut nicht benötige. Wenn ich nur den Mausklick auswerten will, warum muss ich zum Teufel mousePressed() implementieren? Warum muss ich das als anonyme Klasse implementieren? Warum muss ich mein Code komplett mit dem Mist zukleistern? Schlimmer ist ja noch, wenn man Benutzerdefinierte Events hat. Ich habe 30 Zeilen Code geschrieben um nur ein (1) Event auslösen zu können… Warum? Weil… Man benötigt eine Collection für die Listeners, man benötigt Methoden für den Collection (add, remove, size), man benötigt ein Interface, man benötigt eine Methode als Auslöser… und und und… OMG… In C# sind das ganze 3 Zeilen Code… 2 wenn man den DefaultEvent nutzt…
-
/*Edit*/ Parameterübergabe mit by Reference – geht nicht … Man muss den Umweg über Klassen gehen.
Und warum ist das so? Weil… Java sucks!
Legacy of void 
— Zwang zur Nutzung von Anonymen Klassen?
Was zwingt zur Verwendung von anonymen Klassen?
— @Override hat gar kein Nutzen
Override hat schon einen Nutzen, wenn ich Funktionen innerhalb meiner Vererbungsstruktur ändere kann der Compiler inkonsistenten erkennen.
— Getter Setter vollkommen Käse
Es ist nicht verboten Member öffentlich zu deklarieren und direkt zu verwenden. Ob das besser ist ist von Fall zu Fall sicherlich anders zu bewerten.
— Das Threading ist lächerlich beschränkt
Man kann einen Thread mit wait() und notify() durchaus anhalten und fortsetzen.
— abstract methods in Nicht-Abstrakte Klassen
stimmt geht nicht, aber wozu auch, wie soll eine Instanz der Klasse die abstrakte Methode ausführen
— Überladen von Operatoren
Zum Glück, eines der schlimmsten Möglichkeiten unverständlichen und fehlerträchtigen Code in C++ zu erzeugen :-))
— Primitive Datentypen
Einem Objekt kann man kein Primitive zuweisen, das handelt aber der Compiler mit Autoboxing
— Trennung zwischen Code und GUI
Warum soll das nicht möglich sein?
— Events/Listeners
Eine schöne Sache 😉
Komplexe Listenerinterfaces haben in der Regel AdapterImplementierungen, bspw. MouseAdapter für MouseListener, in denen alle Funktionen implementiert sind und nur die notwendigen implementiert werden müssen.
Genau genommen hat jede Sprache ihre Macken, ist alles Gewöhnungs- und Geschmacksfrage:-)))))
– Zwang zur Nutzung von Anonymen Klassen?
Was zwingt zur Verwendung von anonymen Klassen?
————————————————————————–
Ich meine das Hauptsächlich im Zusammenhang mit den Events… Eine andere Möglichkeit gibt es nicht…
-Edit- Ein anderes Beispiel wäre z.B. setFilenameFilter vom FileDialog…
Aber Hauptsächlich stört mich das, wie gesagt, bei den Events…
– @Override hat gar kein Nutzen
Override hat schon einen Nutzen, wenn ich Funktionen innerhalb meiner Vererbungsstruktur ändere kann der Compiler inkonsistenten erkennen.————————————————————————–
OK… dann… Ist das nur wirklich nur Compiler Sache…
– Getter Setter vollkommen Käse
Es ist nicht verboten Member öffentlich zu deklarieren und direkt zu verwenden. Ob das besser ist ist von Fall zu Fall sicherlich anders zu bewerten.————————————————————————–
Ja schon… Aber das macht man nicht 🙂 … Ausserdem kann man dann kein Code bei der Zuweisung ausführen…
– Das Threading ist lächerlich beschränkt
Man kann einen Thread mit wait() und notify() durchaus anhalten und fortsetzen.
————————————————————————–
Hab das schon probiert… Mein Thread hällt zwar an, aber beim notify habe ich multiple Instanzen von Javaw.exe… Ich werde das noch mal ausprobieren, vielleicht liegt der Fehler eher an meinem Code…
– abstract methods in Nicht-Abstrakte Klassen
stimmt geht nicht, aber wozu auch, wie soll eine Instanz der Klasse die abstrakte Methode ausführen
————————————————————————–
Java hat soetwas wie „Mustoverride“ nicht… Wozu das gut ist… Folgende Situation… Ich habe eine Nicht-Abstrakte Klasse, dass auch nicht final ist. Aber… Wenn ich diese Klasse erbe, möchte ich, dass bestimmte Methoden immer überschrieben werden. In Java habe ich dann nur die Möglichkeit die Klasse abstract zu machen um diese Methode als abstract deklarieren zu können. Oder… Ich lasse die Klasse Nicht-Abstract und informiere einfach die Programmierer, dass sie immer diese Methode immer Überschreiben müssen… 🙂
– Überladen von Operatoren
Zum Glück, eines der schlimmsten Möglichkeiten unverständlichen und fehlerträchtigen Code in C++ zu erzeugen )
————————————————————————–
Ja richtig, stimme vollkommen zu 🙂 … Es hat aber auch sein Nutzen… „Overusing“ ist zwar immer ein Problem… Und schlechte Implementierung auch…
– Primitive Datentypen
Einem Objekt kann man kein Primitive zuweisen, das handelt aber der Compiler mit Autoboxing
————————————————————————–
🙂 Compilertrick … Ist wie bei C# und die Autoproperties… Man kann
public int Value {
get { return this.value; }
set { this.value = value; }
}
auch so schreiben
public int Value { get; set; }
Intern macht der Compiler dann den Copperfield… 🙂
— Trennung zwischen Code und GUI
Warum soll das nicht möglich sein?
————————————————————————–
Naja… Man muss selbst darum kümmern, dass Code und GUI auch getrennt sind… Man hat eine Klasse für den Code und eine Klasse für die GUI… Was ich meine ist z.B. wie beim WPF
— Events/Listeners
Eine schöne Sache
Komplexe Listenerinterfaces haben in der Regel AdapterImplementierungen, bspw. MouseAdapter für MouseListener, in denen alle Funktionen implementiert sind und nur die notwendigen implementiert werden müssen.
————————————————————————–
Ja schon… Aber wenn ich wie gesagt MouseListener implementiere, muss ich alle Methoden aus dem MouseListener interface auch Überschreiben…
Extrem einfach wäre z.B. (Ein Beispiel aus Visual Basic NET; sorry dass ich nur gerade Beispiele aus C# und VB nehme…) wenn man nur folgendes machen könnte…
private event x(byval str as string)
raiseevent x(„huhu“)
Btw… ich habe vergessen zu erwähnen… Java hat kein Parameterübergabe by reference… 🙂
Genau genommen hat jede Sprache ihre Macken, ist alles Gewöhnungs- und Geschmacksfrage:-)))))
————————————————————————–
Wooooord… bzw. Richtig 🙂 …
Ich habe auch noch nicht die perfekte Sprache gefunden… Nein Ruby ist auch nicht perfekt… 🙂
Ich will auch gar keine perfekte Sprache… Das wäre ja langweilig, wenn ich mich gar nicht beim programmieren aufregen könnte…
Und ein Programmierer sollte nicht Sprachgebunden sein…