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?

Neue Version vom Apache JSPWiki

Das Apache JSPWiki is ein Wiki-System auf der Basis einfacher Java-Technologien Servlets und JSP. Apache JSPWiki gibt es nun in der Version 2.10, Details unter http://jspwiki.apache.org/.

Some of its features include:

  • WikiMarkup/Structured Text
  • File attachments
  • Templates support
  • Data storage through your choice of two WikiPage Providers, with the capability to create and plug in new ones
  • Security: fine grained control over authorization and authentication, yet simple to configure
  • Easy plugin interface
  • UTF-8 support
  • JSP-based
  • Easy-ish installation
  • Page locking to prevent editing conflicts
  • Support for Multiple Wikis

Doch wohl keine Collection-Literale in Java 9

So ist aktuell Stand der Dinge: http://mail.openjdk.java.net/pipermail/lambda-dev/2014-March/011938.html in Referenz zu http://openjdk.java.net/jeps/186:

Just to close the loop here, we've reached the conclusion that we will 
not be pursuing collection literals as a language feature right now, but 
instead proceeding in the short term with a library-based proposal that 
is similar to what Stephen has described here, with a few ideas from 
Guava's ImmutableXxx classes.