Java does not suck, ABER …

Java löst bei eigenen Menschen tiefere Aggressionen aus, die dann nur mit 5 Stunden Katzenvideos zu besänftigen sind. In den Tenor will ich nicht einsteigen, da ich Java an sich geil finde und die meisten Kritiken nicht teile: langsam, nicht wirklich plattformunabhängig, GC kommt zur Unzeit, geprüfte/ungeprüfte Ausnahmen, kein private protected, kein Sprachkonstrukt für Properties, keine überladene Operatoren, nicht dynamisch genug, Swing ist langsam, kein Modulsystem, Sicherheitsprobleme, …

Dafür sind es andere (kleinere) Dinge, die mich nerven:

  • Der Java-Bibliothek merkt man das Alter an. Vieles ist damals einfach in den “Container” java.util gewandert, und was warum gibt es eigentlich System und Runtime? Von Markierungsschnittstellen Serializable und RandomAccess kommen wir auch nicht mehr weg, der Vorteil ist aber, dass ein instanceof-Test billig ist. Collections ist ein Sammelsurium von Methoden rund um Collection-Typen. Warum wurden die Methoden nicht auch bei den Collection/List-Objekten festgemacht? Ein List#sort(…) wurde ja mittlerweile nachgereicht.
  • Wir haben für die gleiche Aufgabe gleich mehrere Bibliotheken in der der Java SE. Es gibt drei Gui-Komponentenbibliotheken (AWT, Swing, JavaFX), zwei Datei-APIs (java.io.File und java.nio mit Files, Path, Paths, …), zwei Datum-Zeit-APIs (Date/Calendar und java.time in Java 8).  Neueinsteiger in Projekten werden bei Datum/Zeit vermutliche eine wilde Mischung aus Date/Calendar, Joda-Time und bald Java 8 Date-Time-API finden.
  • Immer mehrere Logging-Frameworks im Projekt und folglich unterschiedliche Konfigurationen. Als es java.util.logging (JUL) noch nicht gab, war log4j quasi Standard. Dann kam JUL, log4j wolle man vereinigen, also kam Meta-Logging wie Commons Logging, später SL4J. Dann wurde es ruhig um log4j, neue Produkte kamen, wie logback. Jetzt startet Log4j 2 wieder durch …
  • Die Unterscheidung zwischen primitiven Datentypen und Wrapper-Typen wird immer irrer, schaut man auf Java 8 in das java.util.function-Paket: BooleanSupplier, DoubleBinaryOperator, DoubleConsumer, DoubleFunction<R>, DoublePredicate, DoubleSupplier, DoubleToIntFunction, DoubleToLongFunction, DoubleUnaryOperator, IntBinaryOperator, IntConsumer, IntFunction<R>, IntPredicate, IntSupplier, IntToDoubleFunction, IntToLongFunction, IntUnaryOperator, LongBinaryOperator, LongConsumer, LongFunction<R>, LongPredicate, LongSupplier, LongToDoubleFunction, LongToIntFunction, LongUnaryOperator, ObjDoubleConsumer<T>, ObjIntConsumer<T>, ObjLongConsumer<T>, ToDoubleBiFunction<T,U>, ToDoubleFunction<T>, ToIntBiFunction<T,U>, ToIntFunction<T>, ToLongBiFunction<T,U> , ToLongFunction<T> (OMG!) Ähnliches in javafx.beans.property auch noch mal.
  • Oracle-Webseiten verschwinden, Sun-Seiten wurden nicht übertragen.  Für die kommende Version vom Buch muss ich zwangsläufig alle Links prüfen, viele leiten auf übergeordnete Seiten weiter und sind verschwunden. Bei einer Seite wie http://docs.oracle.com/javase/7/docs/technotes/tools/ erwartet man, dass man 7 durch 8 ersetzen kann und dann kommt man irgendwie bei der Doku von Java 8 aus, oder? Ist aber nicht so …
  • Bug-Base-IDs und Links stimmen oft nicht, Bug gibt es angeblich nicht.
  • toString()-Methoden sind i.d.R. Debug-Methoden, warum implementiert ein Array –Objekt kein vernünftiges toString()?
  • GlassFish ist nicht mehr kommerziell supported wobei es die RI ist. Wie soll man Kunden dann für so ein tolles Produkt begeistern können?
  • Kein standardisiertes Web-Framework bis aus JSF, das reicht nicht. In der Microsoft-Welt hat man erkannt, dass man auch ein (anderes) MVC-Framework braucht, dort gib es ASP.NET MVC Framework und das klassische ASP.
  • Zwei Compiler; der Standard-Compiler und der Eclipse-Compiler (EJC) sind auf unterschiedlichem Niveau und gibt es neue Java-Version, bauen die Eclipse-Macher alles nach. Das dauert und die Compiler sind nicht identisch. Compiler werden immer komplexer.
  • Unklare Zukunft von NetBeans. Bei NB gibt es nach der kommenden Version NB 8.0 (erwartet April 2014) überhaupt keine Zukunftsaussagen. Viele Entwickler sind aus NB abgezogen worden, ob es überhaupt weiter geht und in welchem Tempo ist offen.
  • Unklare Aussage über die Zukunft von Bibliotheken. Wie wird sich GWT weiter entwickeln? Was ist mit anderen Projekten? Oftmals wird das Intervall von Code-Änderungen immer größer, die Projektseite erfährt keine Updates und das Projekt schläft ein. Wie viele UML-Tools sind schon gekommen und gegangen?
  • Oracle hat in Java 7-Updates 51 die Sicherheitsrichtlinien für belegbare Ports verschärft, mit der Konsequenz dass plötzlich Derby nicht mehr läuft und somit alle Standard-Tutorials für JDBC/JPA schon am Anfang eine Hürde nehmen müssen: “The default socket permissions assigned to all code including untrusted code have been changed in this release. Previously, all code was able to bind any socket type to any port number greater than or equal to 1024. It is still possible to bind sockets to the ephemeral port range on each system. The exact range of ephemeral ports varies from one operating system to another, but it is typically in the high range (such as from 49152 to 65535). The new restriction is that binding sockets outside of the ephemeral range now requires an explicit permission in the system security policy..”
  • Suche in Javadoc ist immer noch nicht möglich, ein wenig JavaScript könnte nicht schaden.

Was nervt euch?

Ähnliche Beiträge

7 Gedanken zu “Java does not suck, ABER …

  1. Du hast das Chaos beim Multithread/Lock/Concurrent-jetzt noch besser (mit immer neuen Klassen) vergessen.

    Arrays passen nicht richtig zu Generics und Collections: ein Kuddelmuddel

    Literale für Listen etc.

    immer das blöde Gefrickel mit den Vorzeichen weil es kein unsigned int gibt 🙂

    checked Exceptions: haben sich in anderen Sprachen nicht durchgesetzt

    Die JavaBean-Spec mit den gettern/settern: mittlerweile völlig konfus mit JPA vermischt, es gab NIE wirkliche GUI-Designer „für Beans“ (der urspüngliche Zweck), eigentlich heute überflüssig

    Mein Lieblingsfeature in Scala: Paare, Tripel, … wenn eine Funktion zwei Werte zurückgeben soll, dann kann man sie einfach in ein Tupel packen ohne dass man gleich die nächste sinnlose Klasse nur für diese einen Einsatzzweck schreiben muss

    XML: ein kleines Dokument in einen DOM-Baum parsen erzeugt wieviel immer gleichen Boilerplate-Code?

    es ist zu aufwendig, immutable objects zu erstellen (bzw. man muss gut aufpassen, damit man nicht irgendeine Hintertür offenlässt)

    die „null“, mit Option wird das Chaos jetzt noch größer

    (disclaimer: Java ist tatsächlich die beste verfügbare Programmiersprache/Umgebung: wenn ich die Wahl hätte würde ich immer Java wählen; die Liste der Pluspunkte wäre wesentlich länger)

  2. – Primitive Typen und Generics, passen einfach nicht zusammen

    – Aufgeblasende Runtime, Corba hätte es auch als Library getan, sax und alles xml Zeugs auch. Hoffe da immernoch etwas auf die Profiles. Man zieht bis heute noch Vector und Co mit, hoffe sie haben mal etwas Mut alte Zöpfe abzuschneiden.

    – Unordnung in der Runtime, mal ist was in util, mal in den Wrapper-Typen, java.io und java.nio ….

    – Signed Byte!!!!!

    – Schlechte Unterstützung für Immutable Klassen (keine Immutable Listen oder Arrays)

    – Paketierungsschlacht für Web Projekte, das Projekt Setup dauert immer

    – Signed Byte!!!!!

    – Keine bessere template Engine als JSF (ich mag Razor eigentlich ganz gut). Diese Pseudo-HTML Elemente hass ich wie die Pest.

    – Einfache Helper-Methoden. Ein File.readLines(string path) ist zwar nicht flexibel, aber etwas was man sehr häufig braucht.

    – Die Checked Exceptions könnte man etwas reduzieren.

    – Wenn schon XML, dann mit XQuery. Aber besser gleich als Bibliothek.

    – Signed Byte!!!!! Mal ehrlich, wer hat je in C/C++ signed byte benutzt? Schon eine IPv4 Adresse als Byte-Array benötigt abenteuerliche Rechnungen. Guava hat da nicht umsonst einige Hilfsmethoden drin.

    Collection Litterals brauch ich jetzt nicht dringend. Einige gescheite Factorymethoden List.of(T…. a) und List.of(Iterable elements) können schon ohne neuen Syntax einiges abdecken.

  3. Vor brauchen wir jetzt endlich unbedingt eine aktuelle umfassende Sammlung von best practices für Standardaufgaben in fast allen relevanten Bereichen (IO, Netzwerk, XML, Datenbanken, Threads, Collections,…), ich bin mir mittlerweile völlig unsicher, ob das was ich tue nicht unnötig komplex oder gar völlig überflüssig ist, weil längst neue bessere Methoden existieren…

  4. „das Alter“ :

    Dieser Punkt resoniert am Stärksten mit mir und ich auch nicht mehr bereit dies zu den „kleineren Dingen“ zu zählen. Java beginnt den Zustand von C++ von vor einigen Jahren anzunehmen. Die meisten anderen deiner Kritikpunkte sind meiner Meinung nach bloß Symptome des Alters von Java (zuviele Bibliotheken für X, kein Standard für Y, mehrere Z…). All diese Symptome machen es schwer aus alten Sourcen zu lernen, junge Programmierer anzutrainieren und lassen Java generell komplexer erscheinen als es ist.

    „Oracle-Webseiten verschwinden“:

    Oracle hosted javadoc auf ihren Seiten? Echt? Gibt’s da zu einen Link auf StackOverflow? 🙂
    Spaß beiseite, viele deiner anderen Kritikpunkte sind Kritik an Oracle und ihrem Marketing mit Java. Die Wichtigkeit einer großen Firma und ihrer Beziehung zu einer Open Source Plattform hat mich schon immer fasziniert/verwirrt. Hättest du Interesse einen Blogpost zu dem Thema zu schreiben ;-)?

    „kein Update der JLS“:

    Das hat mich überrascht! Aber warum nervt es dich? Zählt das auch zu den publicity Punkten?

    „Zukunft von Bibliotheken“:

    Ist das nicht ein philosophisches Problem? Niemand kann klare Aussagen über die Zukunft treffen (besonders nicht Open Source Projekte) und denjenigen die es tun kann man nicht trauen. Sie werden dich enttäuschen, wenn du ihnen nur genug Zeit gibst;-).

    Hier noch einige meiner eigenen Nörgeleien:

    – Die Existenz von null, ein Paradoxon ohne gleichen

    – Standardmäßig, kann sich alles in Java ändern, Zustände lassen sich leicht verstreuen. Es ist fast unmöglich eine beliebige Klasse aus einem beliebigen Projekt zu lesen und zu verstehen und vorherzusehen was sie tut, obwohl dies angeblich die große Stärke von Oo und encapsulation ist. Natürlich KANN man immutable objects benutzen und an alles ein finał klatschen (wobei das noch lange keine unveränderbarkeit garantiert) aber Java lädt dazu nicht gerade ein.

    – higher order functions. Lambdas sind ein willkommenes Pflaster auf die Wunde aber noch immer nicht the real deal 🙂

    – packages sind nicht modular genug, in dem Sinne, dass es schwer ist sie voneinander zu trennen (weil einfach alles zu jeder Zeit importiert werden kann) und sie keine Objekte sind, die man zum Beispiel anderen packages übergeben kann, damit klar ist welche Abhängigkeiten existieren.

    – das JRE ist zu groß (in bytes)

    – Java ohne Eclipse (insert your favorite IDE here) ist wie Suppe essen mit Zahnstocher. Warum das ein Problem ist? Die komplexen Abhängigkeiten die eine Entwicklermaschine erfüllen muss nur um Java-Entwicklung zu unterstützen machen das System tendenziell unstabil und nervig in der Pflege (besonders auf Windows! Updates, gefummel in der registry, PATH,…)

    LG, O.

  5. Zu dem Punkt von Blah:
    es gibt doch Seiten, auf denen man Code Snippets an-/ablegen und mit der Community teilen kann, z.B. http://snippetrepo.com/ oder https://snipt.net/.

    Evtl. könnte man eine solche Snippet-Seite dazu benutzen, „common tasks“ in Java zu pflegen? Man könnte dann z.B. ein Snippet mit #java und #common-task taggen. Per Kommentarfunktion „lebt“ das Snippet und kann aktualisiert werden.

    Was haltet ihr davon? Kenn ihr noch andere gute Snippet-Seiten, oder gibt es evtl. sogar schon etwas in der Art, wie ich es beschrieben habe?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert