http://wiki.netbeans.org/NewAndNoteworthyNB80

Das sieht schon mal ganz gut aus:

 

Die Implementierung ist Teil von e(fx)clipse und (noch) kein Teil vom SWT selbst. Großartige Arbeit.

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?

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.

http://googlecloudplatform.blogspot.de/2014/02/app-engine-190-now-available.html

Details unter http://blog.dejavu.sk/2014/02/21/jersey-2-6-has-been-released-new-and-noteworthy/

http://www.heise.de/newsticker/meldung/TZI-identifiziert-Sicherheitsluecken-in-mit-Cordova-erstellten-Apps-2117556.html

http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html

http://www.heise.de/newsticker/meldung/openHAB-fuer-mehr-Datenschutz-in-der-Heimautomatisierung-2109650.html?wt_mc=rss.ho.beitrag.atom

Bevor NIO.2 in Java 7 einen FileVisitor einführte, musste ein Verzeichnis inklusive aller Unterverzeichnisse selbst abgelaufen werden, um Dateien zu finden. Um das selbst zu realisieren helfen uns die Datenstrukturen und die list(…)-Methode von File.

Dabei sollen Dateien gefunden werden, deren Dateinamen auf regulären Ausdrücken »matchen«. Ein List-Objekt speichert bereits gefundene Dateien, und ein Stack merkt sich via Tiefensuche das aktuelle Verzeichnis, in dem der Algorithmus gerade steht. Anders als bei DeleteTree nutzt diese Implementierung keine rekursiven Methodenaufrufe:

import java.io.*;
import java.util.*;
import java.util.regex.Pattern;

public class FileFinder {
  public static List<File> find( String start, String extensionPattern ) {
    List<File> files = new ArrayList<>( 1024 );
    Queue<File> dirs = Collections.asLifoQueue( new LinkedList<File>() );
    File startdir = new File( start );
    Pattern p = Pattern.compile( extensionPattern, Pattern.CASE_INSENSITIVE );

    if ( startdir.isDirectory() )
      dirs.add( startdir );

    while ( dirs.size() > 0 )
      for ( File file : dirs.remove().listFiles() )
        if ( file.isDirectory() )
          dirs.add( file );
        else if ( p.matcher( file.getName() ).matches() )
          files.add( file );

    return files;
  }
}

Eine Nutzung der Utility-Methode ist einfach, wie etwa die folgenden Zeilen zeigen, um Dokumente mit den Dateiendungen .gif und .jpg zu finden:

String path = new File( System.getProperty(„user.dir“) ).getParent();

System.out.println( „Suche im Pfad: “ + path );

List<File> files = FileFinder.find( path, „(.*\\.gif$)|(.*\\.jpg$)“ );

System.out.printf( „Fand %d Datei%s.%n“,
                   files.size(), files.size() == 1 ? „“ : „en“ );

for ( File f : files )
  System.out.println( f.getAbsolutePath() );

Neu in Java 8 ist eine Erweiterung des Javadoc Tools, die in den Javadoc-Kommentaren Fehler aufspürt. Es heißt DocLint. Aktiviert wird diese Prüfung mit dem Schalter –Xdoclint und es erkennt folgende Gruppen von Fehlern, die auch als Option angegeben werden können:

Gruppe	Beschreibung
accessibility	Prüft auf Probleme mit der Zugänglichkeit der Dokumentation, dass etwa Tabellen immer eine Zusammenfassung besitzen.
html	Erkennt HTML-Fehler, wie fehlende schließende spitze Klammern.
missing	Prüft auf fehlende Elemente, wenn zum Beispiel ein Kommentar fehlt, oder @return.
reference	Prüft alle Referenzen in den Javadoc-Tags, etwa bei @see oder auch ungültige Namen bei @param.
syntax	Prüft allgemeine Syntaxfehler wie nicht ausmaskierte HTML-Zeichen wie “<“, „>“ oder „&“ und nicht existierende Javadoc-Tags

Mögliche Gruppen bei Javadoc und dem DocLint Werkzeug

Zu weitere Optionen der Javadoc-Erweiterung siehe http://download.java.net/jdk8/docs/technotes/tools/windows/javadoc.html.