Methoden-Referenz von Java 8

Je größer Software-Systeme werden, desto wichtiger werden Dinge wie Klarheit, Wiederverwendbarkeit und Dokumentation. Wir haben für unseren String-Comparator eine Implementierung geschrieben, anfangs über eine innere Klasse, später über einen Lambda-Ausdruck. In jedem Fall haben wir Code geschrieben. Doch was wäre, wenn eine Utility-Klasse schon eine Implementierung mitbringen würde? Dann könnte der Lambda-Ausdruck natürlich an die vorhandene Implementierung delegieren, und wir sparen Code. Schauen wir uns das mal an einem Beispiel an:

class StringUtils {
  public static int compareTrimmed( String s1, String s2 ) {
    return s1.trim().compareTo( s2.trim() );
  }    
}

public class CompareIgnoreCase {
  public static void main( String[] args ) {
    String[] words = { "A", "B", "a" };
      Arrays.sort( words, (String s1, String s2) -> 
StringUtils.compareTrimmed(s1, s2) );
      System.out.println( Arrays.toString( words ) );
  }
}

Auffällig ist hier, dass die referenzierte Methode compareTrimmed(String,String) von den Parametertypen und vom Rückgabetyp genau auf die compare(…)-Methode eines Comparator passt. Für genau solche Fälle gibt es eine weitere syntaktische Verkürzung, so dass im Code kein Lambda-Ausdruck, sondern nur noch ein Methodenverweis notwendig ist.

Definition: Eine Methoden-Referenz ist  ein Verweis auf  eine Methode ohne diese jedoch aufzurufen. Syntaktisch trennen zwei Doppelpunkte den Klassenamen bzw. die Referenz auf der linken Seite von dem Methodennamen auf der rechten.

Die Zeile

Arrays.sort( words, (String s1, String s2) -> StringUtils.compareTrimmed(s1, s2) );

lässt sich mit einer Methoden-Referenzen abkürzen zu:

Arrays.sort( words, StringUtils::compareTrimmed );

Die Sortiermethode erwartet vom Comparator eine Methode, die zwei Strings annimmt und eine Ganzzahl zurückgibt. Der Name der Klasse und der Name der Methode sind unerheblich, weshalb an dieser Stelle eine Methoden-Referenz eingesetzt werden kann.

Eine Methoden-Referenz ist wie ein Lambda-Ausdruck ein Exemplar einer funktionalen Schnittstelle, jedoch für eine existierende Methode einer bekannten Klasse. Wie üblich bestimmt der Kontext von welchem Typ genau der Ausdruck ist.

Hinweis: Gleicher Code für eine Methoden-Referenz kann zu komplett unterschiedlichen Typen führen – der Kontext macht den Unterschied:

Comparator<String>                  c1 = StringUtils::compareTrimmed;
BiFunction<String, String, Integer> c2 = StringUtils::compareTrimmed;

Varianten von Methoden-Referenzen

Im Beispiel ist die Methode compareTrimmed(…) statisch, und links vom Doppelpunkt steht der Name eines Typs. Allerdings kann beim Einsatz eines Typnamen die Methode auch nicht-statisch sein, String::length ist so ein Beispiel. Das wäre eine Funktion, die ein String auf ein int abbildet, in Code: Function<String, Integer> len = String::length;.

Links von den zwei Doppelpunkten kann auch eine Referenz stehen, was dann immer eine Objektmethode referenziert.

Beispiel: Während String::length eine Funktion ist, wäre string::length ein Supplier, unter der Annahme, das string eine Referenzvariable ist:

String string = "Goll";
Supplier<Integer> len = string::length;
System.out.println( len.get() );     // 4

System.out ist eine Referenz und eine Methode wie println(…) kann an einen Consumer gebunden werden. Es ist aber auch ein Runnable, weil es println() auch ohne Parameterliste gibt.

Consumer<String> out = System.out::println;
out.accept( "Kates kurze Kleider" );
Runnable out = System.out::println;
out.run();

Ist eine Hauptmethode mit main(String… args) deklariert, so ist das auch ein Runnable:

Runnable r = JavaApplication1::main;

Anderes wäre das bei main(String[]), hier ist ein Parameter zwingend, doch ein Vararg kann auch leer sein.

Statt dass der Name einer Referenzvariablen gewählt wird, kann auch this das Objekt beschreiben und auch super ist möglich. this ist praktisch, wenn die Implementierung einer funktionalen Schnittstelle auf eine Methode der eigenen Klasse delegieren möchte. Wenn zum Beispiel eine lokale Methode compareTrimmed(…) in der Klassen existieren würde, in der auch der Lambda-Ausdruck steht,  und sollte diese Methode als Comparator in Arrays.sort(…) verwendet werden, könnte es heißen: Arrays.sort(words, this::compareTrimmed).

Hinweis: Es ist nicht möglich eine spezielle Methode über die Methodenreferenz auszuwählen. Eine Angabe wie String::valueOf oder Arrays::sort ist relativ breit – bei letzterem wählt der Compiler eine der 18 passenden überladen Methoden aus. Da kann es passieren, dass der Compiler eine falsche Methode auswählt, in dem Fall muss ein expliziter Lambda-Ausdruck eine Mehrdeutigkeit auflösen. Bei generischen Typen kann zum Beispiel List<String>::length oder auch List::length stehen auch hier erkennt der Compiler wieder alles selbst.

Was soll das alles?

Einem Einsteiger in die Sprache Java wird dieses Sprache-Feature wie der größte Zauber auf Erden vorkommen, und auch Java-Profis bekommen hier zittrige Finger, entweder vor Furcht oder Aufregung… In der Vergangenheit musste in Java sehr viel Code explizit geschrieben werden, aber mit diesen neuen Methoden-Referenzen erkennt und macht der Compiler vieles von selbst.

Nützlich wird diese Eigenschaft mit den funktionalen Bibliotheken aus Java 8, die ein eigenes Kapitel einnehmen. Hier nur ein kurzer Vorgeschmack:

Object[] words = { " ", '3', null, "2", 1, "" };
Arrays.stream( words )
      .filter( Objects::nonNull )
      .map( Objects::toString )
      .map( String::trim )
      .filter( s -> ! s.isEmpty() )
      .map( Integer::parseInt )
      .sorted()
      .forEach( System.out::println );   // 1 2 3

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?

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.

Verzeichnisse nach Dateien iterativ durchsuchen (vor Java 7)

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() );

Javadoc-Überprüfung mit DocLint

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.

Inselraus: Applets

»Mode ist, was man selbst trägt. Altmodisch ist, was die anderen tragen.«– Oscar Wilde (1854–1900)

Applets sind kleine Java-Programme, die in einem Webbrowser ablaufen. Sie gehören zu den Java-Programmen der ersten Stunde. Referenziert eine Web-Seite ein Applet, so startet der Browser eine virtuelle Maschine und führt das Applet aus.

Applets in der Wiege von Java

Haben sich in den Anfangsjahren die Browser-Hersteller selbst darum gekümmert, die Applets in ihren Browsern um Laufen zu bringen, hat sich das heute gewandelt. Oracle liefert die Java Plug-In Technology (kurz Java Plug-In) aus, was die Browser bei der Ausführung von Applets auf den gleichen Stand bringt. Das hat den Vorteil, dass  die Java-Technologie auch zum Internet Explorer kommt, da ja Microsoft seine JVM nicht mehr aktualisiert. (Microsoft lieferte für Windows XP immerhin noch eine eigene JVM aus, obwohl sie auf dem Stand von Java 1.1 stehen blieb, aber XP ist ja auch nicht mehr Stand der Dinge.) Früher lief die virtuelle Maschine im Browser selbst, in neuen Java-Versionen läuft die Java-Anwendung in einem eigenen Prozess.

Applets heute

Obwohl Applets Java an die Spitze der Programmiersprachen brachten, sind sie heute nur noch selten zu sehen. Es gibt zwar Ausnahmen, wie den Routenplaner http://www.de.map24.com/ oder diverse Aktien-Chart-Analysen, doch im Allgemeinen sind Applets von öffentlichen Webseiten weitestgehend verschwunden. Der Grund, warum Java-Applets weniger attraktiv für den Konsumenten sind, liegt nicht darin, dass die clientseitige Darstellung und Logik unwichtig geworden ist, sondern vielmehr an anderen Gründen:

  • Mit HTML, CSS sowie JavaScript lassen sich heutzutage viele Aufgaben lösen, die 1995 unlösbar waren. Dagegen wirken compilierte Java-Programme nicht gerade wie Raketentechnik. Während bei Java-Applets erst eine JVM gestartet werden muss, was natürlich eine gewisse Zeit kostet, sind JavaScript und HTML sofort bereit. Starke JavaScript-Bibliotheken ermöglichen tolle Effekte und mit performanten JavaScript-Engines wie der quelloffenen V8 von Google oder TraceMonkey der Mozilla Foundation eine schnelle Verarbeitung.
  • Java ist als allgemeine Programmiersprache entworfen worden, aber nicht als einfache Programmiersprache für grafische Effekte. Hier liegt der Vorteil von Adobe Flash oder auch Microsoft Silverlight. Mit starken Tools können Designer großartige Oberflächen entwerfen, und die Verbreitung des Flash-Players ist phänomenal.[1] Zudem erweitert Adobe die Multimedia-Technologie Flash, die Programmiersprache ActionScript sowie die Produktpalette zur Entwicklung kontinuierlich. Oracle versucht mit der Plattform JavaFX (http://www.oracle.com/technetwork/java/javafx/overview/index.html) dagegenzusetzen, aber JavaFX kann wohl eher Swing für Rich-Clients ablösen und wird wohl im Internet ein Exot bleiben.
  • Ist Java installiert, steht auf den Rechnern eine moderne und schnelle Java-Laufzeitumgebung für Applets über ein Browser-Plugin zur Verfügung. Das Problem beginnt aber, wenn Anwender Applets nutzen möchten (oder müssen), aber kein JVM installiert ist. HTML, CSS und JavaScript sind immer Teil des Browsers, und in der Regel ist auch Flash installiert. Dagegen ist der Bezug einer JVM langwierig, und viele Megabyte Daten müssen vom Oracle-Server geladen werden. (Microsoft lieferte zwar früher für den IE eine JVM mit, doch wegen immer wieder auftretender Sicherheitsprobleme sollten Anwender Microsofts JVM deinstallieren. Microsoft liefert für Vista kein Java mit aus, und daher muss sowieso Oracles JVM installiert werden.[2])

Hinweis: Wir wollen im Folgenden davon ausgehen, dass nicht die Java-Laufzeitumgebung 1.1 von Microsoft installiert ist, sondern ein vollwertiges Java von Oracle. Ist Oracles JVM installiert, ersetzt sie – falls diese installiert war – die JVM von Microsoft, und aktuelle Java-Programme lassen sich ausführen.

(J)Applet und Applikationen

Verfügen normale Applikationen, die von der Kommandozeile gestartet werden, über eine statische main(String[])-Methode, ist das bei Applets anders. Sie erweitern zwingend die Klasse javax.swing.JApplet oder java.applet.Applet und implementieren Callback-Methoden statt einer main(…)-Methode. (Hybride Programme, die sowohl Applikation als auch Applet sind, sind ebenfalls möglich. Diese Sorte Programm erweitert einfach die Klasse (J)Applet und implementiert eine statische main(…)-Methode.)

Ein Applet unterliegt hohen Sicherheitsbestimmungen – eine auf dem Client-Rechner liegende Datei kann zum Beispiel nicht gelöscht werden, und schon der lesende Zugriff ist unzulässig. Vom Sicherheitsstandpunkt aus betrachtet, kontrolliert der SecurityManager die Handlungen der Software.

Das erste Hallo-Applet

Ein Programm wird leicht zu einem Applet, wenn es die Klasse Applet erweitert. Als Einstieg soll ein kleines Beispiel-Applet dienen.

import java.applet.Applet;
import java.awt.Graphics;

 public class HelloWorldApplet extends Applet {
   /* @Override */ public void paint( Graphics g )
   {
     g.drawString( "Hallo Welt!", 50, 25 );
   }
 }

Die beiden ersten import-Anweisungen binden die notwendigen Informationen über Applets und über Zeichenmethoden ein. Das HelloWorldApplet erweitert die Klasse Applet, denn so wird ein Applet erzeugt. Eine statische main(String[])-Methode kommt nicht vor, und es muss eine Methode paint(Graphics) überschrieben werden, die den Bildschirmaufbau übernimmt.[3] Der Webbrowser oder Applet-Viewer ruft diese Methode per Callback auf.

Damit der Viewer weiß, was zu machen ist, gibt der HTML-Code einen Hinweis auf die Klasse, die in die Seite eingebettet wird. Dies wird über ein spezielles Tag erreicht.

<html><body>
<applet code="HelloWorldApplet.class" width="200" height="100"></applet>
</body></html>

Neben dem Namen der Klasse übermittelt das Applet-Tag der virtuellen Maschine auch die Maße des Fensters, in dem das Applet zeichnen kann.

Ab Java 1.1 lassen sich gepackte Dateien im Jar-Format übermitteln. Die Angabe der Klasse in der Code-Anweisung sollte keine Leerzeichen beinhalten. Die Endung .class ist nicht in jedem Browser erforderlich, wird aber empfohlen.

Fehler in Applets finden

Werden Applets vom Browser nicht ausgeführt, weil es Fehler in unserem Programm gibt, so bietet die Java Console (http://www.java.com/en/download/help/javaconsole.xml) die Möglichkeit, Log-Informationen anzusehen und so die Fehler genauer zu studieren.

Die Applet-API

Die Zyklen eines Applets

Beim Start eines Applets werden unterschiedliche Methoden vom Browser automatisch aufgerufen. Es beginnt mit dem Aufruf der Methode init(). Dort sollten Initialisierungen erfolgen. init() wird nur einmal aufgerufen, wenn die Seite vom Browser geladen wird. Nach der Initialisierung folgt ein Wechsel der Methoden start() und stop() immer dann, wenn ein Applet im Browser sichtbar ist oder von der Seite verschwindet, etwa wenn der Anwender über die Schieberegler einen anderen Bereich auswählt, in dem das Applet nicht liegt. Beim Verlassen der Seite wird abschließend destroy() aufgerufen. Dort können Ressourcen freigegeben werden.

Parameter an das Applet übergeben

Dem Applet können Parameter im Applet-Tag übergeben werden. Dazu wird im <applet>-Element ein <param>-Element eingebettet. Im Folgenden zeichnet ein Applet einen grünen oder roten Kasten, in Abhängigkeit davon, ob eine URL korrekt aufgebaut ist.

<html><body>
 <a href="http://tutego.com/index.html">Java-Seminare</a>
 <applet code="CheckUrlApplet.class" width="10" height="10">
 <param name="url" value="http://tutego.com/index.html">
 </applet>
 <p>
 <a href="tutego.com/index.html2">Java-Seminare Falsch</a>
 <applet code="CheckUrlApplet.class" width="10" height="10">
 <param name="url" value="tutego.com/index.html2">
 </applet>
</body></html>

Das Applet nimmt den Parameter an und prüft den gültigen Aufbau der URL über eine MalformedURLException.

import java.applet.Applet;
import java.awt.Color;
import java.awt.Graphics;
import java.net.MalformedURLException;
import java.net.URL;

public class CheckUrlApplet extends Applet {
  private boolean urlOk = false;

  public void init() {
    try {
     new URL( getParameter( "url" ) );
      urlOk = true;
    }
    catch ( MalformedURLException e ) { /* urlOk is false */ }
  }
  @Override public void paint( Graphics g ) {
     g.setColor( urlOk ? Color.GREEN : Color.RED );
     g.fillRect( 0, 0, 10, 10 );
   }
}

Interessant wäre natürlich, wenn das Applet gleich die URL auf Erreichbarkeit prüfen würde. Relativ einfach ergeben sich dann folgende Zeilen:

try {
 urlOk = ((HttpURLConnection)new URL( getParameter("url" ) ).
 openConnection()).getResponseCode() == HttpURLConnection.HTTP_OK;
}
catch ( IOException e ) { /* urlOk is false */ }

Doch bei der Prüfung von üblichen Links kommt es zu einem Fehler! Aus Sicherheitsgründen kann ein Applet nur auf den Rechner zugreifen, von dem es geladen wurde, nicht auf andere. Ohne explizite Sicherheitserweiterungen kann so ein allgemeines Applet zum Prüfen eines Links nicht geschrieben werden.

Wie das Applet den Browser-Inhalt ändern kann *

Das Applet kann mit showDocument(URL [,String]) auf den Inhalt der Seite Einfluss nehmen. So lassen sich Applets bauen, die eine Baumstruktur der Seite anzeigen und dann zum Inhalt verweisen, falls eine Seite ausgewählt wird. Verwendet werden hier die Methoden von AppletContext. In Kurzform:

getAppletContext().showDocument( new URL("http://tutego.com/") );

Oder, falls ein spezieller Frame mit Namen angesprochen ist:

getAppletContext().showDocument( new URL("http://tutego.org"), "Framename" );

class java.applet.Applet extends Panel

  • AppletContext getAppletContext()
    Liefert den Kontext des Applets. Dieser Kontext erlaubt es dem Applet herauszufinden, in welcher Umgebung, also auf welcher Web-Seite, es sich bewegt.

interface java.applet.AppletContext

  • void showDocument(URL url)
    Ersetzt den Inhalt auf der aktuellen Seite durch eine neue Seite von der angegebenen URL.
  • void showDocument(URL url, String target)
    Ersetzt den Inhalt auf der aktuellen Seite durch eine neue Seite von der angegebenen URL. Dabei wird das Dokument in einem Frame abgelegt, dessen Name zusätzlich festgelegt ist. Für target sind erlaubt: _self (Seite, die das Applet enthält), _parent (bettet die neue Seite in die Vaterseite des Applets ein; falls diese nicht existiert, verhält es sich wie _self), _top (im Top-Level-Frame anzeigen; falls dieser nicht existiert, wie _self), _blank (erzeugt ein neues Fenster), und wenn der Name nicht mit den Konstanten übereinstimmt, wird die Anzeige in einen Frame gelegt, der diesen Namen trägt.

Den Ursprung des Applets erfragen

Greift ein Applet auf Daten des Servers zu und ist ihm die Adresse nicht bekannt, so kann es nachfragen. Die Applet-Klasse stellt die Methoden getCodeBase() und getDocumentBase() zur Verfügung.

class java.applet.Applet extends Panel

  • URL getCodeBase()
    Liefert die Basis-URL des Applets.
  • URL getDocumentBase()
    Liefert die URL der Webseite, die das Applet enthält.

Auf dem URL-Objekt liefert getHost() eine String-Repräsentation der URL. So kommen wir mit der Methode getCodeBase().getHost() an den Hostnamen und auch an die Daten des Servers.

Beispiel: Applets können problemlos von Webseiten geklaut werden. Um dem einen Riegel vorzuschieben, können wir verlangen, dass die Zeichenkette von getDocumentBase().getHost() immer die Webseite unseres Servers repräsentiert.

String web = getDocumentBase().getHost();
if ( ! "www.tutego.com".equals(web) ) {
 // hier meckern, dass was nicht stimmt.
}

Wir könnten die Überprüfung auch über ein InetAddress-Objekt realisieren.

class java.net.URL implements Serializable, Comparable

  • String getHost()
    Liefert den Hostnamen des URL-Objekts. Handelt es sich um das »file«-Protokoll, so ist der Rückgabewert ein leerer String.

Beispiel: Baue eine URL-Verbindung zu einer Grafikdatei auf. Wir benutzen hier zunächst die Methode getDocumentBase(), um an die URL des Servers zu gelangen, und anschließend den URL-Konstruktor, der uns relativ zur Basisadresse eine Pfadangabe erlaubt.

URL u1 = getDocumentBase();
try {
URL u2 = new URL( u1, "image.gif" );
   ...
}
catch ( MalformedURLException e ) { ... }

Datenaustausch zwischen Applets *

Sind mehrere Applets auf einer Webseite untergebracht, gibt es Fälle, in denen die Applets Daten austauschen wollen. Zwei Lösungen sind populär:

  • Da alle Applets in einer einzigen JVM laufen, lässt sich über statische Attribute auf die anderen Elemente zugreifen. Dies spricht jedoch gegen die Datenkapselung und ist sehr unfein. Diese Technik hat einen weiteren Schwachpunkt: Statische Variablen hängen eng mit dem Klassenlader zusammen, und hier traten in der Vergangenheit bei einigen Browsern Probleme auf.
  • Eleganter ist da schon die Möglichkeit über die Schnittstelle AppletContext, die es ermöglicht, einen Verweis auf das Applet über den Namen zu bekommen.

class java.applet.Applet extends Panel

  • AppletContext getAppletContext()
    Bestimmt die Umgebung eines Applets.

Applets über den AppletContext erfragen

Mit dem AppletContext gibt es zwei Möglichkeiten, an das Applet zu gelangen:

  • das Applet über einen Namen ansprechen
  • eine Aufzählung aller Applets erfragen

Um einen Namen zu vergeben, wird das name-Attribut im <applet>-Tag genutzt, etwa so:

<applet code="Applet.class" name="applet" width="10" height="10">

Eine Verbindung der Methoden getAppletContext() aus Applet und getApplet(String name) aus AppletContext führt zu folgender Zeile:

Applet anotherApplet = applet.getAppletContext().getApplet( "applet" );

Die zweite Variante war, sich mit getApplets() eine Enumeration aller Applets einer Seite zu besorgen:

Applet otherApplet = null;
Enumeration applets = getAppletContext.getApplets();
while ( applets.hasMoreElements() ) {
 otherApplet = (Applet) applets.nextElement();
 if ( otherApplet != this )
  break;
 // Jetzt können wir etwas mit dem anderen Applet machen
 // if ( otherApplet instanceof Applet2 )
 //   ...
}

interface java.applet.AppletContext

  • Applet getApplet(String name)
    Sucht das Applet namens name in dem Dokument, das durch den AppletContext gegeben ist. Der Name kann durch das HTML-Tag gesetzt sein. Falls kein Applet dieses Namens existiert, liefert die Methode null.
  • Enumeration<Applet> getApplets()
    Findet alle Applets, die durch AppletContext angegeben sind.

Praktische Kommunikation

Das Applet können wir gegebenenfalls in eine Unterklasse casten. Dann lassen sich alle Methoden aufrufen und die Variablen auslesen. Leider funktionieren beide vorgestellten Methoden nur, wenn die Applets in dem gleichen Frame liegen. Liegen sie in verschiedenen Frames, findet zumindest die Netscape-Methode getApplet(String) das Applet leider nicht. Hier bleibt aber noch die Variante über statische Variablen übrig. Eine weitere Möglichkeit, Applets über verschiedene Frames kommunizieren zu lassen, führt über eine JavaScript-Funktion. Sie fungiert als Brücke, was etwa so aussieht: top.frames[1].document.applet[„applet“].method().

Das folgende Beispiel zeigt zwei Applets, Applet1 und Applet2, auf einer Webseite. Zunächst der HTML-Code:

<html><body>
<applet code="Applet1.class" name="applet1" height="200" width="200"></applet><applet code="Applet2.class" name="applet2" height="200" width="400"></applet>
</body></html>

Es folgen die Implementierungen für die beiden Applets:

import java.applet.Applet;
import java.awt.*;

public class Applet1 extends Applet {
   private TextField inputText = new TextField( "", 10 );
   public void init() {
     add( inputText );
     add( new Button( "Sende an Applet2" ) );
   }

   public boolean action( Event ev, Object arg ) {
     if ( ev.target instanceof Button ) {
       Applet2 applet2 = (Applet2) getAppletContext().getApplet( "applet2" );

       if ( applet2 != null )     {
         applet2.appendTheText( inputText.getText().trim() );
         return true;
       }
     }

     return false;
   }
 }

import java.applet.Applet;
import java.awt.TextArea;

public class Applet2 extends Applet {
   private TextArea textBox = new TextArea( 5, 40 );

   public void init() {
     add( textBox );
   }

   public void appendTheText( String s ) {
     textBox.append( s + "\n" );
   }
 }

Da bei verschiedenen Frames getAppletContext() jedoch das andere Applet nicht zurückgeben muss, bleibt nur noch die Variante über die statische Variable. Glücklicherweise lassen sich mit Beobachtermustern aus auch elegante Benachrichtigungen realisieren.

Reiseverbot für Daten: Was ein Applet alles darf *

Ein Applet unterliegt bestimmten Sicherheitsbeschränkungen, die eine Java-Security-Einheit überprüft.

Viele der bekannten Fehler in Java, die potenzielle Sicherheitslücken darstellen, sind mittlerweile behoben. Schon das Auffinden setzt eine gründliche Kenntnis der Java-Quelltexte voraus, beispielsweise der Fehler mit der Host-Adresse: Wenn ein Benutzer ein Applet von tutego.com liest, darf dieses Applet nur mit diesem Host eine Verbindung aufbauen und mit keinem anderen. Doch leider gab es in den Quelltexten von Java einen Fehler, sodass das Applet nur den Rechnernamen des Hosts vergleicht, nicht aber die IP-Adresse. Ein bösartiges Applet kann nun dem DNS (Domain Name Server) eine falsche Zuordnung von Rechnername und IP-Adresse vorspielen, und nun verhält sich tutego.com wie www.ganz-boese.com.

Ist Java im Browser aktiviert? *

Wenn unser Browser Java-Applets ausführen soll, aber Java gar nicht aktiviert ist, dann lassen sich einige interaktive Benutzeraktionen nicht durchführen. Wir sollten daher zumindest eine Meldung anbieten, dass der Browser Java gerade nicht aktiviert hat. Dies kann beabsichtigt oder nicht beabsichtigt sein. Natürlich kommt Java dafür nicht infrage, aber eine Skript-Sprache mit einem ähnlichen Namen: JavaScript. Ab JavaScript-Version 1.1 bietet uns der Interpreter die Funktion javaEnabled() an, sodass wir eine Weiterschaltung vornehmen können:

if ( ! navigator.javaEnabled() ) {
 self.location.href = "nix_mit_java.html";
}

Für diese Lösung muss natürlich JavaScript aktiviert sein. Für einige Surfer ist selbst dies schon eine Sicherheitslücke, und wenn JavaScript deaktiviert ist, lässt sich hier nichts mehr machen. Falls JavaScript aktiviert ist, kommen wir dem Benutzer einen Schritt entgegen, sodass er nicht mehr manuell angeben muss, ob Java aktiv ist oder nicht. Von dieser Technik sollten wir auch Gebrauch machen, denn nicht immer hat der Benutzer bewusst Java abgeschaltet. Im Beispiel oben haben wir eine Seite angesteuert, wobei natürlich andere Anweisungen denkbar sind. Doch diese Form ist sinnvoll, denn wir können Benutzern eine Kurzbeschreibung darüber liefern, wie Java im Browser aktiviert wird. Zusammen mit der Browservariante ist eine browsergenaue Beschreibung einsetzbar.

Applet unter Firefox (Netscape) oder Microsoft Internet Explorer? *

Kann der Browser ein Applet aus irgendwelchen Gründen nicht ausführen, so sind die Meldungen an den Benutzer meist mager. Oft beschränken sie sich auf eine Exception-Angabe in der Statuszeile. Dies mag keiner mehr sehen. Doch leider verschärfen inkompatible Browser die Situation. Was hier Abhilfe schafft, ist ein kleines Programm, das zunächst herausfindet, auf welchem Browser das Applet läuft. Dann können unter Umständen browser- und versionsabhängige Varianten ausgeführt werden.

Wir verwenden einen Trick, der auch beim Erkennen von Prozessortypen angewendet wird: Wir versuchen, Klassen zu laden oder Methoden aufzurufen, die es für den jeweils anderen Browser nicht gibt. Der Internet Explorer hat zum Beispiel eine private Klasse com.ms. applet.GenericAppletContext, und Mozilla hat eine Klasse netscape.applet.MozillaAppletContext. Löst die JVM beim Laden der Klasse eine Exception aus, wissen wir Bescheid, um welchen Browser es sich handelt.

Versuchen wir, über die selbst gebastelten Methoden isNetscape() und isMicrosoft() etwas über unsere Laufzeitumgebung herauszufinden.

import java.applet.Applet;

public class BrowserDetector extends Applet {

 public void init() {
     if ( isNetscape() )
       System.out.println( "Netscape, Firefox, ... Browser." );

     if ( isMicrosoft() )
       System.out.println( "Microsoft Browser." );
   }

   public static boolean isNetscape() {
     try {
       Class.forName( "netscape.applet.MozillaAppletContext" );
     }
     catch ( ClassNotFoundException e ) { return false; }
     return true;
   }

   public static boolean isMicrosoft() {
     try {
       Class.forName( "com.ms.applet.GenericAppletContext" );
     }
     catch ( ClassNotFoundException e ) { return false; }
     return true;
   }
 }

Die Idee lässt sich natürlich auch anwenden, um Java-Versionen zu testen; es wird einfach eine Klasse erfragt, die bei einer neuen Java-Version hinzugekommen ist, bei Java 2 etwa Point2D.

Tipp: Da nicht immer sichergestellt sein kann, dass Java in einer vernünftigen Version (>= 1.2) auf dem Client-Rechner der Benutzer installiert ist, lässt sich ein Test-Applet vorschalten, das zunächst die Java-Version prüft. Anschließend kann dieses Eingangs-Applet über getAppletContext().showDocument() auf eine andere Seite mit einem Applet verweisen. Für unterschiedliche Browser und Java-Installationen können somit unterschiedliche Applets auf die Situation eingehen.

Webstart

Bevor Software auf dem Rechner läuft, wird sie in der Regel installiert. Dazu legen die Hersteller der Software ein spezielles Installationsprogramm bei – unter Windows oft die InstallShields. Das Installationsprogramm legt passende Verzeichnisse an und initialisiert etwa die Registrierdatenbank unter Windows. Etwas anders sieht das bei Java-Programmen aus. Die Installation erfordert zuerst eine Java-Laufzeitumgebung. Anschließend kann das Programm entpackt und gestartet werden. Wünschenswert ist jedoch eine Art Umgebung, wie sie bei Java-Applets definiert ist. Ein Java-Applet läuft innerhalb eines Browsers in einem speziellen Sicherheitsmodus, und es wäre günstig, wenn dies auch für alle anderen Applikationen möglich wäre. Das bedeutet: Eine beliebige Applikation kann von einer Webseite geladen und auf dem lokalen Rechner ausgeführt werden. Die Applikation soll sich nicht von anderen Applikationen unterscheiden, die lokal installiert sind.

Damit der Start möglich ist, ist die Oracle-Technologie Webstart nötig. Webstart deckt die Bereiche Installation, Start und Update durch ein eigenes Protokoll ab, das Java Network Launcher Protocol (JNLP). Die Technologie wurde auf der JavaOne 2000 erstmals vorgestellt. Neben der offiziellen Webseite widmet sich auch die (nicht mehr ganz so frische) Unofficial Java Web Start/JNLP FAQ unter http://lopica.sourceforge.net/faq.html dem Thema.

Zum Weiterlesen

Die API rund um Applets blieb lange Zeit stabil und unaufregend. Mit einer neuen Browser-Implementierung und Annäherung an WebStart passiert aber doch noch das ein oder andere. So können Applets mittlerweile aus Web-Seiten herausgezogen werden, und Applets können problemlos den DOM-Baum der Seite modifizieren, in der sie laufen. Mehr Informationen zu diesen Themen gibt es in Oracles Java-Tutorial unter http://download.oracle.com/javase/tutorial/deployment/applet/index.html. Es gibt auch von Oracle eine JavaScript-API, die das korrekte HTML für ein Applet generiert, sodass Entwickler nicht das eigentlich veraltete <applet> nutzen müssen – Weiteres dazu unter http://download.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_advice.html#deplToolkit.


[1]    http://www.adobe.com/products/player_census/flashplayer/version_penetration.html

[2]    http://windowshelp.microsoft.com/Windows/en-US/Help/59c3a93d-1342-43a6-a01a-f720c7a17ffc1033.mspx

[3]    Das gilt nicht für JApplet. Dort ist das Überschreiben von paint() oder paintComponent() unüblich, da im Allgemeinen eine eigene, sich zeichnende Komponente auf das JApplet gesetzt wird.

Kommen in Java 9 nun Collection Literals?

Neu ist die http://openjdk.java.net/jeps/186, schauen wir, was wird. Ziel “Being able to initialize arrays, lists, sets, and maps with a compact expression”. Wobei ich die Syntax jetzt nicht so schön finde:

List<Integer> list = #[ 1, 2, 3 ];

Die Diskussion unter http://mail.openjdk.java.net/pipermail/lambda-dev/2014-January/011671.html ist schon recht lang ausführlich.