Laut Media Control ist mein Java-Buch das bestverkaufte Computing-Buch des Jahres 2013. Ausgewertet wurden alle Titel zu Computing-Themen (Programmierung, Netze, Server, Web ) aller Verlage.
Insel
toString(), toGenericString(), getCanonicalName() in Class
Die Klasse Class überschreibt die Methode toString() und greift dabei auf getName() zurück. toString() fügt zusätzlich Informationen über die Art des repräsentierten Typs (normale Klasse, Schnittstelle oder primitiver Datentyp) ein. Neu in Java 8 ist toGenericString(), was auch noch in spitzen Klammern die Typvariablen anzeigt. (Natürlich nicht den Typparameter, da der zur Laufzeit wegen der Typlöschung nicht bekannt ist.) Um die Typvariable zu erfragen wird getTypeName() verwendet; die Methode ist eine Implementierung aus der Schnittstelle Type, die Class implementiert.
Beispiel: Teste für ein Class-Objekt die drei String-Repräsentationen:
Class<?> c = HashMap.class;
System.out.println( c.getName() ); // java.util.HashMap
System.out.println( c.toString() ); // class java.util.HashMap
System.out.println( c.toGenericString() ); // public class java.util.HashMap<K,V>
Bei inneren Typen trennt ein $ bei der String-Repräsentation den äußeren und inneren Typ. Anders verhält sich getCanonicalName(), wie das Beispiel zeigt:
|
Anweisung |
Rückgabe |
|
Map.Entry.class.getName() |
java.util.Map$Entry |
|
Map.Entry.class.getCanonicalName() |
java.util.Map.Entry |
|
Map.Entry.class.toString() |
interface java.util.Map$Entry |
|
Map.Entry.class.toGenericString() |
public abstract static interface java.util.Map$Entry<K,V> |
String-Repräsentation bei inneren Typen
Alle Neuerungen von Java 8 über die Javadoc finden
Im folgenden Beispiel wollen wir ein kleines Doclet schreiben, das Klassen, Methoden und Konstruktoren ausgibt, die das Tag @since 1.8 (bzw. @since 8, was aber eigentlich falsch ist) tragen. So lässt sich leicht ermitteln, was in der Version Java 8 alles hinzugekommen ist. Doclets werden normalerweise von der Kommandozeile aufgerufen und dem javadoc-Tool übergeben. Unser Programm vereinfacht das, indem es direkt das Tool über Java mit dem passenden Parameter aufruft. tools.jar muss dafür im Klassenpfad sein und die Dokumentation ausgepackt am angegeben Ort.
package com.tutego.tools.javadoc;
import java.util.*;
import java.util.function.Predicate;
import com.sun.javadoc.*;
import com.sun.tools.javadoc.Main;
public class SinceJava8FinderDoclet {
public static boolean start( RootDoc root ) {
for ( ClassDoc clazz : root.classes() )
processClass( clazz );
return true;
}
private static void processClass( ClassDoc clazz ) {
Predicate<Tag> isJava18 = tag -> tag.text().equals( "8" ) || tag.text().equals( "1.8" );
if ( Arrays.stream( clazz.tags( "since" ) ).anyMatch( isJava18 ) )
System.out.printf( "Neuer Typ %s%n", clazz );
for ( MethodDoc method : clazz.methods() )
if ( Arrays.stream( method.tags( "since" ) ).anyMatch( isJava18 ) )
System.out.printf( "Neue Methode %s%n", method );
for ( ConstructorDoc constructor : clazz.constructors() )
if ( Arrays.stream( constructor.tags( "since" ) ).anyMatch( isJava18 ) )
System.out.printf( "Neuer Konstruktor %s%n", constructor );
for ( FieldDoc field : clazz.fields() )
if ( Arrays.stream( field.tags( "since" ) ).anyMatch( isJava18 ) )
System.out.printf( "Neues Attribut %s%n", field );
}
public static void main( String[] args ) {
String[] params = {
"-quiet", "-XDignore.symbol.file",
"-doclet", SinceJava8FinderDoclet.class.getName(),
"-sourcepath", "C:/Program Files/Java/jdk1.8.0/src/",
// "java.lang", // Nur java.lang
"-subpackages", "java:javax" // Alles rekursiv unter java.* und javax.*
};
Main.execute( params );
}
}
Unsere main(String[])-Methode ruft das JDK-Doclet-Programm über Main.execute(String[]) auf und übergibt die eigene Doclet-Klasse per Parameter – die Argumente von execute(String[]) erinnern an die Kommandozeilenparameter. Das Doclet-Hauptprogramm wiederum ruft unsere start(RootDoc root)-Methode auf – das Gleiche würde auch passieren, wenn das Doclet von außen über javadoc aufgerufen würde. Unser start(RootDoc) läuft über alle ermittelten Typen und übergibt zum Abarbeiten der Innereien die Verantwortung an processClass(ClassDoc). Die Metadaten kommen dabei über diverse XXXDoc-Typen. Ein Precidate zieht den Tag-Test heraus, ein weiterer Einsatz der neuen Java 8 Streams würde das Programm nicht übersichtlicher machen.
Das Programm nutzt ein paar Tricks, um die Ausgabe auf das Wesentliche zu konzentrieren. Der Schalter –quit schaltet den üblichen Ladestatus, der zu Ausgaben wie
Loading source files for package java.lang…
Loading source files for package java.applet…
Loading source files for package java.awt…
führt ab.
Der Schalter -XDignore.symbol.file wiederum unterdrückt Meldungen wie diese hier:
C:\…\src\java\lang\Class.java:57: warning: Unsafe is internal proprietary API and may be removed in a future release
import sun.misc.Unsafe;
^
Die Meldungen landen auf dem System.err-Kanal, sodass sie sich auch mit System.setErr(…) in einem ausgabeverwerfenden Strom geschickt werden können um sie zu unterdrücken.
Besonderheit bei vererbten Konstruktoren mit Ausnahmen
Implementiert eine Unterklasse einen eigenen Konstruktor, und ruft dieser super(…) für einen Konstruktor auf, der eine Ausnahme auslöst, so muss auch der Konstruktor der Unterklasse diese Ausnahme melden, denn der neue Konstruktor kann die Ausnahme nicht auffangen. In unsere Beispiel wäre also
public SubRandomAccessFile( File file, String mode ) {
try {
super( file, mode );
} catch ( Exception e ) { }
}
illegal. Der Grund ist ganz einfach: Wenn der Konstruktor der Oberklasse eine Ausnahme auslöst, ist das Objekt nicht vollständig initialisiert. Und wenn der Konstruktor der Unterklasse dann die Ausnahme abfängt, würde ja die Unterklasse vielleicht nicht vollständig initialisierte Eigenschaften der Oberklasse erben, also ein halbgares Objekt. Das ist unerwünscht.
Singleton in Java
Ein Singleton ist eine Klasse, von der es in einer Anwendung nur ein Exemplar gibt. Nützlich ist das für Dinge, die es nur genau einmal in einer Applikation geben soll, und davon gib es einige Beispiele:
· Eine grafische Anwendung hat nur ein Fenster.
· Eine Konsolenanwendung hat nur je einen Eingabe-/Ausgabestrom.
· Alle Druckaufträge wandern in eine Drucker-Warteschlage.
Unbestreitbar ist, dass es einmalige Objekte gibt, variantenreich ist jedoch der Weg dahin. Im Prinzip lässt sich unterscheiden zwischen einem Ansatz, bei dem
a) ein Framework sich um den einmaligen Aufbau des Objekts kümmert und dann auf Anfrage das Objekt liefert oder
b) wir selbst in Java-Code ein Singleton realisieren.
Die bessere Lösung ist ein Framework zu nutzen, namentlich CDI, Guice, Spring, Java EE, doch Java SE enthält keines davon, weswegen wir zur Demonstration den expliziten Weg gehen.
Die technischen Realisierungen sind vielseitig; in Java bieten sich zur Realisierung von Singletons Aufzählungen (enum) und normale Klassen an. In Folgendem wollen wir ein Szenario annehmen, bei dem eine Anwendung zentral auf Konfigurationsdaten zurückgreifen möchte.
Singletons über Aufzählungen
Eine guter Weg für Singletons bieten Aufzählungen – auf den ersten Blick scheint ein enum nicht dafür gemacht, denn eine Aufzählung impliziert ja irgendwie mehr als ein Element – doch die Eigenschaften vom enum sind perfekt für ein Singleton. Die Idee dabei ist, genau ein Element anzubieten, gerne INSTANCE genannt, was letztendlich ein Exemplar der Aufzählungskasse wird, und die normalen Methoden:
public enum Configuration {
INSTANCE;
private Properties props = new Properties( System.getProperties() );
public String getVersion() {
return "1.2";
}
public String getUserDir() {
return props.getProperty( "user.dir" );
}
}
Der Typ Configuration deklariert neben der später öffentlichen statischen Variable INSTANCE auch noch eine interne Variable props, die von der Aufzählung genutzt werden kann, um dort Zustände abzulegen oder zu erfragen. Wir machen das im Beispiel nur lesend über getUserDir().
Ein Nutzer greift wie üblich auf die enum-Eigenschaften zu:
System.out.println( Configuration.INSTANCE.getVersion() ); // 1.2
System.out.println( Configuration.INSTANCE.getUserDir() ); // C:\Users\…
Singletons über Klassen
Ein alternativer Weg – und der übliche vor Java 5 – arbeit mit einer Klasse und privatem Konstruktor, zusammen mit einer statischen Anfrage-Methode, die das Objekt liefert:
public class Configuration2 {
private static final Configuration2 INSTANCE = new Configuration2();
public final static Configuration2 getInstance() {
return INSTANCE;
}
private Configuration2() {
}
private Properties props = new Properties( System.getProperties() );
public String getVersion() {
return "1.2";
}
public String getUserDir() {
return props.getProperty( "user.dir" );
}
}
Interessant sind einmal der private Konstruktor und zum anderen die statische Anfrage-Methode getInstance(). Wenn ein Konstruktor privat ist, bedeutet das noch lange nicht, dass keine Exemplare mehr erzeugt werden können. Ein privater Konstruktor besagt nur, dass er von außen nicht sichtbar ist – aber die Klasse selbst kann ihn ebenso wie private Methoden »sehen« und zur Objekterzeugung nutzen. Objektmethoden kommen dafür nicht in Frage, da ähnlich wie beim Henne-Ei-Problem ja vorher ein Objekt nötig wäre. Es bleiben somit die statischen Methoden als Erzeuger. Und das ist das, was wir wollen: Keine Exemplare von außen, nur von innen. Und da die statische Variable INSTANCE ja genau ein Objekt referenziert, kann die statische Methode diese Referenz nach außen geben.
Die Nutzung der zweiten Variante ist nicht sonderlich unterschiedlich, hat aber wohl eine andere Syntax, sodass ein Refactoring von einer Lösung in die andere Codeänderungen nach sich zieht:
System.out.println( Configuration2.getInstance().getVersion() ); // 1.2
System.out.println( Configuration2.getInstance().getUserDir() ); // C:\Users\…
Oftmals findet sich in Implementierungen eines Singletons noch eine Optimierung, in dem erst in getInstance() das Exemplar aufgebaut wird. Dazu muss aber noch die Methode mit synchronized ausgezeichnet werden, was vor nebenläufigen Zugriffen schützt, sodass nur ein Thread die Methode betreten kann und ein potenziell anderer Thread so lange warten muss, bis der erste Thread die Methode wieder verlassen hat.
Deklarative und programmierte Oberflächen: Swing und JavaFX im Vergleich
Grundsätzlich können grafische Oberflächen über eine Programm-API aufgebaut werden oder in einer deklarativen Beschreibung spezifiziert werden.
· Programmierte Oberflächen: Der traditionelle Bau von grafischen Oberflächen in Java weist die Besonderheit auf, dass das Design der Oberfläche in Java-Code gegossen werden muss. Jede Komponente muss mit new erzeugt werden und mithilfe eines Layouts explizit angeordnet werden. Komplexe Oberflächen bestehen dann aus fast unwartbaren Mengen von Programmcode zum Aufbau der Komponenten, zum Setzen der Eigenschaften und Platzierung auf dem Container. Die Änderung des Layouts ist natürlich sehr schwierig, da mitunter auch für kleinste Änderungen viel Quellcode bewegt wird. In der Versionsverwaltung sieht das mitunter schrecklich aus.
· Deklarative Oberflächen stehen im Gegensatz zu den programmierten Oberflächen. Bei ihnen ist die Beschreibung des Layouts und die Anordnung der Komponenten nicht in Java ausprogrammiert, sondern in einer externen Ressourcen-Datei beschrieben. Das Format kann etwa XML sein, und spiegelt wieder, wie das Objektgeflecht aussieht. Eine Ablaufumgebung liest die Ressourcen-Datei und übersetzt die Deklarationen in ein Geflecht von GUI-Komponenten. Im Hauptspeicher steht dann am Ende das gleiche wie bei der programmierten GUI: ein Objekt-Graph.
Das andere Ufer: Microsoft erkannte ebenfalls die Notwendigkeit einer deklarativen Beschreibung von Oberflächen und nutzt intensiv XAML (Extensible Application Markup Language). Gleichzeitig gibt es leistungsfähige Tools und Designer für XAML. Die Firma Soyatec versucht sich mit eFace an einer Java-Realisierung (http://www.soyatec.com/eface/).
Gui-Beschreibungen in JavaFX
JavaFX unterstützt beide Möglichkeiten zum Aufbau von grafischen Oberflächen. Zum einen ist da die klassische API, die Knoten in einen Baum hängt, viel interessanter ist aber der deklarative Ansatz, der sehr schön Präsentation und Logik trennt. JavaFX selbst bietet eine Beschreibung auf XML-Basis, genannt FXML. XML ist selbst hierarchisch, kann also die grundlegende hierarchische Gliederung einer GUI in Containern und Komponenten sehr gut abbilden.
Neben FXML gibt es weitere proprietäre Beschreibungen und Mischformen. Eine davon ist FXGraph vom Projekt e(fx)clipse (http://www.eclipse.org/efxclipse/), einer JavaFX-Unterstützung in Eclipse. Die Beschreibung ist eine DSL[1] und definiert den Objekt-Graphen, der im Hintergrund in FXML umgesetzt wird. FXGraph ist kompakter als FXML und erinnert entfernt an JSON. Auch kann die JavaFX-API in alternativen Sprachen angesprochen werden, JavaScript und weitere Skriptsprachen wie Groovy (und der Hilfe von GoovyFX[2]) oder Scala (zusammen mit ScalaFX[3]) zeigen interessante Wege auf. Allerdings mischt sich dann doch wieder schnell die Deklaration der GUI mit Logik, was die Trennung zwischen Präsentation und Logik aufweicht. Es ist guter Stil, die Beschreibung der Benutzerschnittstelle und der Logik zu trennen, um auch Tests leichter zu realisieren.
Deklarative GUI-Beschreibungen für Swing?
Für AWT und Swing hat sich für deklarative Oberflächen in den letzten Jahren kein Standard gebildet, und Oberflächen werden heute noch so programmiert wie vor 15 Jahren. Dass Swing-Oberflächen immer programmiert werden müssen hält auf, auch wenn ein GUI-Builder heutzutage die Schmerzen minimiert. Über die WYSIWYG-Oberfläche wird in der Regel das Layout mit allen Komponenten zusammengeklickt und im Hintergrund erzeugt der GUI-Builder den Programmcode. Für die Laufzeitumgebung hat sich also nichts verändert, aber für uns schon.
Um auch in Swing in die Richtung von deklarativen Oberflächen zu kommen, gibt es unterschiedliche Open-Source-Lösungen, da Oracle nichts im Angebot hat.
· Swixml (http://www.swixml.org/) nutzt das XML-Format zur Beschreibung von GUIs und bildet jede Swing-Klassen auf ein XML-Element ab. Später nutzt Swixml dann SAX und JDOM, um die XML-Datei einzulesen und zu repräsentieren und um zur Laufzeit eine Swing-Komponentenbaum aufzubauen. Die Folien unter http://www.swixml.org/slides.html geben einen Einblick in die Möglichkeiten. Seit Mitte 2011 wird Swixml nicht mehr erweitert.
· Eine weitere Lösung zur deklarativen Beschreibung von Swing-Oberflächen bietet der Swing JavaBuilder (http://code.google.com/p/javabuilders/). Die Open-Source-Bibliothek steht unter der Apache-Lizenz und nutzt statt XML das kompaktere YAML-Format, dessen Schreibweise noch weiter verkürzt wurde. Das letzte Release stammt von Ende 2011, eine Weiterentwicklung ist unwahrscheinlich.
Die Inaktivität lässt entweder so erklären dass die Produkte perfekt sind, oder sich Entwickler mit den klassischen Code-generierenden GUI-Buildern anfreunden konnten, oder die Tools mit dem Aufkommen von JavaFX einfach unattraktiv werden.
[1] Eine domain-specific-language (DSL) ist eine „Spezialsprache“, die ein exklusives Format für einen klar abgegrenzten Anwendungsfall definiert.
Geschichte von JavaFX: JavaFX 1, JavaFX 2, JavaFX 8
Ursprünglich wollte Sun/Oracle JavaFX als Flash-Ersatz im Internet positionieren, doch dafür ist die Kombination HTML5 + CSS3 + JavaScript zu attraktiv. JavaFX ist in erster Linie eine großartige GUI-Bibliothek für klassische Client-Anwendungen, die langsam auch auf mobile Endgeräte vorrückt. So nahm die Entwicklung auch unterschiedliche Richtungen an.
JavaFX ist schon sehr lange in Entwicklung und viele interne Swing-Entwickler wurden bei Sun/Oracle auf das Projekt angesetzt – umgekehrt passierte bei AWT/Swing nicht mehr viel, Bugfixes kommen aber immer noch brav. Im Jahr 2007 wurde JavaFX auf der SunOne-Konferenz vorgestellt, Ende 2008 erschien das Release JavaFX 1.0 zusammen mit der Programmiersprache JavaFX Script. Die besondere Sprache machte es einfach möglich, hierarchische Objektgrafen aufzubauen, und bot eine nette Syntax für Object-Binding, sodass Zustände synchronisiert werden konnten.
Im Oktober 2011 erschien JavaFX 2.0 mit vielen Neuerungen und auch Änderungen. So wurde JavaFX Script entfernt, denn Oracle wollte keine weitere Programmiersprache aufbauen, sondern eine pure Java API, die Entwickler dann von unterschiedlichen existierenden Skriptsprachen ansprechen können. Das ist sicherlich eine gute Entscheidung, denn unter JavaScript und Groovy[1] sieht das sehr schlank aus, fast wie mit JavaFX Script. Mit dem Update auf JavaFX 2.0 ändert sich auch die API, sodass alter Code angefasst werden musste. Heute ist JavaFX 1.x ist veraltet, genauso wie die Literatur.
JavaFX entwickelte sich immer mehr als Alternative zu Swing/AWT und so integrierte Oracle im August 2012 das Java FX 2.2 SDK und die Runtime in das JDK 7u6 and JRE 7u6. Der Schritt war ungewöhnlich, denn so große Ergänzungen waren bisher im JRE/JDK noch nie gemacht worden. Neben der Integration bewegte sich auch das ehemals geschlossene JavaFX in Richtung Open-Source und mündete in der Implementierung OpenJFX. Mit dem OpenJDK und OpenJFX lässt sich ein komplett freies Java-System mit GUI-Stack unter der GPL bauen, was strikte Linux-Distributionen freuen wird. Die Offenheit führte schon zu sehr spannenden Experimenten, etwa einer Java-Version für iOS.
Mit Java 8 zieht auch JavaFX 8 fest in die Distribution ein, der nächste Sprung mit 3D-Unterstützung.
Pack200-Format
Jar-Dateien enthalten in der Regel eine Mischung aus Klassendateien und Ressourcen. Die Jar-Archive sind normale Zip-Archive und somit steht der bekannte Zip-Algorithmus hinter der Kompression. Das liefert eine befriedigende Kompression über alle Formate, bietet aber keine besonderen Kompressionsverfahren für gewissen Dateitypen. Eine optimale Kompression ist aber gerade bei Jar-Bezug über das Internet wünschenswert. Während JPG-Dateien von Zip auch nicht besser komprimiert werden können, verkürzen sich Klassendateien schon etwas, erreichen mit Zip aber immer noch nicht das Maximum einer möglichen Komprimierung. Das liegt daran, dass Zip eine .class-Datei wie normalen Binärcode betrachtet und den Aufbau der Java-Klassendateien eben nicht kennt. Hier kommt ein spezielles Format zum Zuge, was den Aufbau von Klassendateien berücksichtigt, das Pack200-Format. Neben dem Dienstprogramm jar bietet das JDK im bin-Verzeichnis auch entsprechende Kommandozeilenwerkzeuge pack200 und unpack200 zum Komprimieren und eben Dekomprimieren.
Beispiel: Die Eclipse-Installation bringt genug Jar-Dateien mit, an denen Pack200 ausprobiert werden kann. Unter eclipse\plugins\org.apache.ant_1.8.4.v201303080030\lib nehmen wir uns ant.jar vor, ein Jar-Archiv von 1.941.731 Bytes.
$ pack200.exe -O ant.jar.pack.gz ant.jar
Der Schalter -O optimiert noch etwas und am Ende steht eine Datei ant.jar.pack.gz von 502.721 Bytes, also eine fast viermal kleinere Version.
Das pack200-Tool arbeitet im Prinzip so, dass es eine Jar-Datei nimmt, die Einträge umsortiert, Redundanzen erkennt und in einer Art neue spezielle Mega-Klassendatei verpackt[1], die dann mit dem Standard-GZip-Verfahren komprimiert wird.[2] Pack200- Dateien tragen in der Regel die Dateiendung *.jar.pack.gz und ein Web-Server serviert sie unter dem MIME-Typ application/x-java-pack200. Bezieht ein Programm über Java Web Start oder ein Java Plug-in die Dateien, so werden diese direkt ausgepackt und wie ein Jar eingebunden.
[1] Details und Anwendung zum Verfahren gibt Die Oracle-Seite http://download.java.net/jdk8/docs/technotes/guides/jweb/networking/compression_formats.html#pack200_compression. Intern ist das Verfahren komplex und die Beschreibung über die internen Vorgänge lang, siehe http://docs.oracle.com/javase/7/docs/technotes/guides/pack200/pack-spec.html.
[2] Während jede normale Klassen-Datei mit der Hex-Kennung 0xCAFEBABE beginnt, beginnt der Container der Pack-Datei mit 0xCAFED00D (Cafe Dude) – sympathisch.
Wiederholbare Annotationen: @Repeatable
Normalerweise nutzen Entwickler Annotationen wie einmalige Modifizierer, und es ergibt keinen Sinn, etwa @Override @Override String toString() zu schreiben, genauso wenig wie es keinen Sinn ergibt final static final double PI zu deklarieren. Doch da es durchaus Meta-Daten gibt, die mehrmals auftauchen können, gibt es seit Java 8 eine Erweiterung, dass Annotationen wiederholt werden dürfen. Allerdings müssen die Annotationstypen dieser wiederholbaren Annotationen selbst mit einer besonderen Meta-Annotation @Repeatable ausgezeichnet werden. Damit ist es aber noch nicht getan, denn @Repeatable muss als Element einen Typ bekommen, der den Container angibt.
Beispiel: Der Annotationstyp für Autoren kann so aussehen:
public @interface Author { String name(); }
Soll nun die Annotation mehrfach verwendet werden, ist die Meta-Annotation nötig und mit ihr die Angabe eines Containers:
@Repeatable( Authors.class )
public @interface Author { String name(); }
Der Container ist selbst ein Annotationstyp mit einem Feld als Element. Der Typ des Feldes ist exakt der wiederholbare Annotationstyp.
public @interface Authors {
Autor[] value;
}
Ohne @Repeatable am Annotationstyp wird eine mehrmalige Verwendung einer Annotation zu einem Compilerfehler führen. Im Java SE 8 gibt es bisher keine Verwendung dieses Annotationstyps, also auch keine wiederholbaren Annotationen.
@Target Annotation seit Java 8
Die Meta-Annotation @java.lang.annotation.Target beschreibt, wo eine Annotation angeheftet werden kann. Ist kein ausdrückliches @Target gewählt, gilt es für alle Elemente, die Annotation kann also etwa an Klassen stehen, aber auch an lokalen Variablen. In der Regel gibt es bei @Target ein Element, und das ist von der Aufzählung java.lang.annotation.ElementType; es deklariert die folgenden Ziele:
|
ElementType |
Erlaubt Annotationen … |
|
ANNOTATION_TYPE |
nur an anderen Annotationstypen, was @Target(ANNOTATION_TYPE) somit zu einer Meta-Annotation macht. |
|
TYPE |
an allen Typdeklarationen, also Klassen, Schnittstellen, Annotationstypen, Aufzählungen. |
|
CONSTRUCTOR |
an Konstruktor-Deklarationen |
|
METHOD |
an Deklarationen von statischen und nicht-statischen Methoden. |
|
FIELD |
an Deklarationen von statischen Variablen und Objekt-Variablen. |
|
PARAMETER |
an Parametervariablen von Methoden. |
|
LOCAL_VARIABLE |
an lokalen Variablen. |
|
PACKAGE |
an package-Deklarationen. |
|
TYPE_PARAMETER |
an der Deklaration einer Typ-Variablen für generische Typ-Parameter. Neu in Java 8. Wenn es etwa heißt class List<@AnAnnotation T>. |
|
TYPE_USE |
an allen Stellen, wo Typen eingesetzt werden, adressiert also Typ-Annotationen. Ebenfalls neu in Java 8. So etwas wie @NonNull (keine Annotation aus der Java SE!) ist ein Beispiel |
Tabelle 1.3: ElementType bestimmt Orte, an denen Annotationen erlaubt sind.
Orte für Annotationen
Annotationen lasen sich setzen an allen Deklarationen und bei Typnutzungen (ab Java 8).
|
Deklarationen |
Typnutzung |
|
Typendeklarationen (Klassen, Schnittstellen, Aufzählungen, anderen Annotationtypen) |
new-Operator |
|
Eigenschaften (Konstruktoren, Methoden, Attributen) |
Typ-Anpassung |
|
implements-Klausel |
|
|
throws-Klausel bei Methoden |
Wo Annotationen möglich sind
Die Annotationen bei der Typnutzung nennen sich kurz Typ-Annotationen.
Java bringt einige Annotationstypen mit, doch die werden bisher ausschließlich für Deklarationen eingesetzt, wie das gekannte @Override. Vordefinierte Typ-Annotationen sind bisher in der Java SE nicht zu finden.
Mit Locking Dateien sperren
Damit eine Datei gegen konkurrierenden parallelen Zugriff geschützt ist, lässt sie sich über Locking absichern. Um einen Lock für Dateien zu erwerben bietet die Java-API ein FileLock-Objekt. So ein FileLock bekommt ein Programm von der Methode lock() eines FileChannels – ein FileChannel wiederum kommt von getChannel(), einer Methode, die FileInputStream, FileOutputStream oder RandomAccessFile anbieten.
Beispiel: Öffne eine Datei, erzeuge exklusiven Zugriff, und schreibe Daten:
FileOutputStream fos = new FileOutputStream( file );
try ( FileLock fileLock = fos.getChannel().tryLock() ) {
fos.write( … );
}
Hinweis: Die übliche Schreibweise OutputStream fos funktioniert natürlich nicht, da ein allgemeiner OutputStream keine getChannel()-Methode bietet.
Die lock(…)-Methode liefert als Ergebnis ein FileLock-Objekt. Das wiederum bietet einige Methoden, wobei für uns nur release() bzw. close() interessant sind, die den Lock wieder freigeben. FileLock implementiert die Schnittstelle AutoCloseable, sodass ein FileLock auch auch try-mit-Ressourcen verwendet werden kann, wie im Beispiel geschehen.
Um zu testen, ob eine gegebene Datei gelockt ist, lässt sich tryLock() verwenden – etwa mit der folgenden statischen Hilfsmethode:
public static boolean isLocked( String filename ) {
try ( RandomAccessFile raf = new RandomAccessFile( filename, "rw" ); FileLock lock = raf.getChannel().tryLock() ) {
// Nothing to do here
}
catch ( IOException e ) {
return false;
}
return true;
}
Die Methoden tryLock(…) und lock(…) liefern FileLock-Objekt und diese Ressource muss immer korrekt geschlossen werden.
Hinweis: Unter Unix-Systemen gibt es kein eindeutig vorgeschriebenes Verfahren zum File-Locking[1], sodass Oracle das Sperren bisher nur so umsetzt, dass zwei Java-Programme sich gegenseitig nicht in die Quere kommen, es aber sein kann, dass ein anderes Unix-Programm diesen Lock nicht respektiert. So kann unter Unix eine Datei von mehreren Seiten gelesen werden, selbst wenn ein Java-Programm sie aktuell beschreibt. Auch kann eine Datei auf dem Dateisystem gelöscht werden, selbst wenn das Java-Programm sie noch offen hält. Das Windows-Betriebssystem unterstützt hingegen Locks. Wenn ein Prozess keinen Lock auf die Datei besitzt, kann der Prozess die Datei auch nicht lesen.
[1] Zum Beispiel mit dem Alleskönner fcntl() aus dem POSIX-Standard oder flock() von 4.2 BSD.
try-mit-Ressourcen auf null-Ressourcen
Das immer zum Abschluss eines try-mit-Ressourcen-Blocks ein close() aufgerufen wird ist nicht ganz korrekt; es gibt nur dann ein Schließversuch, wenn die Ressource ungleich null ist.
Beispiel
Der Codebaustein compiliert und führt zu einer Konsolenausgabe.
try ( Scanner scanner1 = null; Scanner scanner2 = null ) {
System.out.println( "Ok" );
}
Bei Konstruktoren ist ein Objekt ja immer gegeben, aber es gibt auch Fabrikaufrufe, bei denen vielleicht null herauskommen kann, und für diese Fälle ist es ganz praktisch, dass try-mit-Ressourcen dann nichts macht, um eine NullPointerException beim close() zu vermeiden.
Alternative Sprachen für die JVM
Die hochoptimierte JVM und die umfangreichen Java-Bibliotheken lassen sich mittlerweile durch alternative Programmiersprachen nutzen. Auf der einen Seite existieren klassische Interpreter und Compiler für existierende Sprachen, wie Ruby, Prolog, LISP, BASIC, Python, die bestmöglich auf die Java-Umgebung portiert werden. Auf der anderen Seite sind es ganz neue Programmiersprachen (wie schon das genannte Groovy), die sich als echte Alternative zur Programmiersprache Java etablieren. Skriptsprachen werden oft über die JSR 223: Scripting for the Java Platform, einer standardisierten API, angesprochen.
Dieser Abschnitt gibt einen kleinen Überblick über aktuelle Programmiersprachen auf der JVM. Im ersten Teil geht es um existierende Programmiersprache, die auf die JVM gebracht werden.
JavaScript
Seit Java 6 ist eine JavaScript-Laufzeitumgebung integriert. Die Script-Engine erlaubt die dynamische Übersetzung in Bytecode, was schnelle Ausführungszeiten der funktionalen objektorientierten Programmiersprache garantiert.
JRuby
JRuby (http://jruby.org/) ist die Java-Version der dynamisch getypten Programmiersprache Ruby (http://www.ruby-lang.org/). Ruby wird mit einem Atemzug mit dem Web-Framework Ruby on Rails genannt, ein Framework für Web-Applikationen, welches dank JRuby auch auf jedem Tomcat und Java Application-Server läuft.
Jython
Die beliebte Programmiersprache Python (http://www.python.org/) bringt Jython (http://jython.org/) auf die Java-Plattform. Auch Jython übersetzt Python-Programme in Java-Bytecode und erlaubt relativ schnelle Ausführungszeiten. Jython 2.5 implementiert Python auf 2.5, doch hat sich (C-)Python mit Version 2.7 und 3.3 auch schon weiter entwickelt. Auch sonst gibt es Unterschiede, etwa bei den eingebauten (nativen) Funktionen.
Quercus
Quercus (http://quercus.caucho.com/) ist eine Implementierung der Programmiersprache PHP, entwickelt von Caucho Technology. Mit Quercus lasen sich viele beliebte PHP-Projekte in einer Java-Umgebung ausführen. In der Java-Welt werden zwar nicht alle PHP-Funktionen unterstützt, aber dafür gibt es in der Java-Welt keine Speicherüberläufe oder Sicherheitsprobleme.
Clojure
Die Programmiersprache Clojure (http://clojure.org/) ist ein LISP-Dialekt und fällt so in die Kategorie der funktionalen Programmiersprachen. Der Compiler erzeugt direkten Byte-Code. Für die Kommandozeile gibt es ein kleines Tool (Read-Eval-Print-Loop (REPL)), mit dem jeder erste Versuche von der Kommandozeile machen kann. Seit einiger Zeit gibt es auch Umsetzungen für .NET und JavaScript.
LuaJava
Eine Umsetzung der Programmiersprache Lua (http://www.lua.org/) für die JVM ist LuaJava (http://www.keplerproject.org/luajava/) bzw. Juaj (http://sourceforge.net/projects/luaj/). Die aus Brasilien stammende dynamisch getypte Programmiersprache Lua zählt zu den performantesten, interpretierten Skriptsprachen. Sie ist in erster Linie als eingebettete Programmiersprache zur Applikationssteuerung entworfen worden; prominente Nutzer sind Sim City, World of Worcraft, Adobe Photoshop Lightroom, SciTE, weiter unter http://www.lua.org/uses.html.
JLog
JLog (http://jlogic.sourceforge.net/) implementiert einen ISO-standardisierten PROLOG-Interpreter. JLog läuft in einem eigenen Fenster mit Quellcode-Editor, Query-Panel, Hilfe, Debugger, oder es kann in einem eigenen Java-Programm eingebettet werden.
Die Wikipedia-Seite https://en.wikipedia.org/wiki/List_of_JVM_languages führt weitere Programmiersprachen für die JVM auf. Allerdings sind viele der gelisteten Sprachen für sehr spezielle Anwendungsfälle entworfen, experimentell oder werden nicht mehr gepflegt.
Die genannten Implementierungen bringen eine bekannte Sprache auf die Java Umgebung, so dass zum Beispiel Code zwischen Plattformen ausgetauscht werden kann. Es gibt auch komplette Neuentwicklungen für neue Programmiersprachen.
Groovy
Groovy bietet eine starke Syntax mit Closures, Listen/Mengen, reguläre Ausdrücke, eine dynamische und statische Typisierung und vielem mehr. Moderne IDEs wie Eclipse oder NetBeans unterstützen Groovy durch Plugins (http://groovy.codehaus.org/Eclipse+Plugin, http://groovy.codehaus.org/NetBeans+Plugin). Der Groovy-Compiler erzeugt für die Groovy-Klassen den typischen Bytecode, sodass normale Java-Klassen problemlos Groovy-Klassen nutzen können – oder umgekehrt.
Scala
Scala ist eine funktionale, objektorientierte Programmiersprache, die in der Java-Community große Zustimmung findet. Plugins für diverse Entwicklungsumgebungen stehen ebenfalls bereit. Auch für die .NET-Plattform gibt es Implementierung. Besonders zeichnet Scala ein durchdachtes Typsystem aus. Für viele Entwickler ist es „Java 2.0“.
In den letzten Jahren sind vermehrt neue JVM-Programmiersprachen aufgetaucht, sie sind vom Sprachdesign auf jeden Fall interessant, finden aber bisher kaum großen Einsatz. Zu diesen zählen etwa Fantom (http://fantom.org/), Ceylon (http://ceylon-lang.org/) oder Gosu (http://gosu-lang.org/).
Geschichte: Als Java noch unter der Sonne stand, stellte Sun zentrale Entwickler ein, um die Weiterentwicklung von Skriptsprachen unter der JVM zu unterstützen. Darunter etwa im März 2008 Frank Wierzbicki, Hauptentwickler von Jython. Doch schon nach 1,5 Jahren verließ er Sun wieder.[1] Das gleiche Spiel mit den Entwicklern von JRuby, Charles Nutter und Thomas Enebo, die 2006 zu Sun gingen und 2009 das Unternehmen in der Oracle- Akquisationsphase verließen.[2] NetBeans bot den besten (J)Ruby-Editor, doch entfernte die Version NetBeans 7.0 die Unterstützung komplett.[3]
[1] http://fwierzbicki.blogspot.de/2009/11/leaving-sun.html
[2] http://news.idg.no/cw/art.cfm?id=C0D2078D-1A64-6A71-CE889FFB617BA47D
Nebenläufigkeit und Parallelität
Computersysteme lösen Probleme in der echten Welt, sodass wir zur Einstieg auch in der Realwelt bleiben, um uns dem Umfeld der nebenläufigen Programmierung zu nähern.
Gehen wir durch die Welt bemerken wir viele Dinge, die gleichzeitig passieren: Die Sonne scheint, auf der Straße fahren Mofas, Autos werden gelenkt, das Radio spielt, Menschen sprechen, einige essen, Hunde tollen auf der Wiese. Nicht nur passieren diese Dinge gleichzeitig, sondern es gibt mannigfaltige Abhängigkeiten, wie Wartesituation: an der roten Ampel warten einige Autos, während bei der grünen Ampel Menschen über die Strasse gehen – beim Signalwechsel dreht sich das Spiel um.
Wenn viele Dinge gleichzeitig passieren, nennen wir ein interagierendes System nebenläufig. Dabei gibt es Vorgänge, die echt parallel ausgeführt werden können, und bei machen Dingen sieht es so aus, als ob sie parallel passieren, aber in Wirklichkeit passiert es nur schnell hintereinander. Was wir dann wahrnehmen, ist eine Quasiparallelität. Wenn zwei Menschen etwa gleichzeitig essen, ist das parallel, aber wenn jemand isst und atmet, so sieht dass zwar von außen gleichzeitig aus, ist es aber nicht, sondern schlucken und atmen ist sequenziell[1]. Auf Software übertragen: die gleichzeitige Abarbeitung von Programmen und Nutzung von Ressourcen nebenläufig ist; es ist eine technische Realisierung der Maschine (also Hardware), ob diese Nebenläufigkeit durch parallele Abarbeitung – etwa durch mehre Prozessoren oder Kerne – auch wirklich umgesetzt wird.
Nebenläufige Programme werden in Java durch Threads realisiert und im Idealfall findet die Abarbeitung auch parallel statt, wenn die Maschine mehrere Prozessoren oder Kerne hat. Ein Programm, was nebenläufig realisiert ist, kann durch zwei Prozessoren bzw. Kerne in der parallelen Abarbeitung in der Zeit halbiert werden, muss es aber nicht, es ist immer noch Sache des Betriebssystems, wie es die Threads ausführt.
[1] lassen wir Kleinkinder einmal außen vor
Kommandozeilenprogramm jcmd für Diagnosekommandos
Mit dem Kommandozeilenprogramm jcmd lassen sich Diagnosekommandos zu einer laufenden JVM schicken. Die Java-Programme werden wieder über eine PID identifiziert, die jcmd auch anzeigen kann:
$ jcmd.exe
2484 C:\Users\Christian\eclipse\\plugins/org.eclipse.equinox…
18868 sun.tools.jcmd.JCmd
Eclipse hat die PID 2484 und das Tool selbst – das bei jedem Starten natürlich eine neue PID bekommt – 18868.
Interessant wird jcmd dadurch, dass sich Diagnose-Kommandos senden lassen. Als erstes steht die PID, dann folgt das Kommando. Um ein Übersicht über die Häufigkeit von geladen Klassen zu bekommen ist GC.class_histogram zu nutzen:
$ jcmd.exe 2484 GC.class_histogram
2484:
num #instances #bytes class name
----------------------------------------------
1: 600676 40906520 [C
2: 549996 13199904 java.lang.String
3: 121570 4862800 java.util.WeakHashMap$Entry
4: 117120 3747840 java.lang.ref.WeakReference
5: 63926 2730616 [Ljava.lang.String;
…
Auf der Hilfeseite sind die Kommandos nicht aufgeführt, weil sie abhängig von der jeweiligen JVM sind und nicht im Tool jcmd selbst verankert sind. Daher müssen sie dynamisch von einem laufenden Java-Programm erfragt werden. Unser Elcipse-Prozess hatte die PID 2484, und dann kommt die Option help zum Einsatz:
$ jcmd.exe 2484 help
2484:
The following commands are available:
VM.native_memory
VM.check_commercial_features
VM.unlock_commercial_features
ManagementAgent.stop
ManagementAgent.start_local
ManagementAgent.start
Thread.print
GC.class_stats
GC.class_histogram
GC.heap_dump
GC.run_finalization
GC.run
VM.uptime
VM.flags
VM.system_properties
VM.command_line
VM.version
help
For more information about a specific command use 'help <command>'.
Wie die letzte Zeile verrät, gibt ein angehängtes Kommando weitere Informationen, etwa
$ jcmd.exe 2484 help GC.heap_dump
2484:
GC.heap_dump
Generate a HPROF format dump of the Java heap.
Impact: High: Depends on Java heap size and content. Request a full GC unless th
e '-all' option is specified.
Permission: java.lang.management.ManagementPermission(monitor)
Syntax : GC.heap_dump [options] <filename>
Arguments:
filename : Name of the dump file (STRING, no default value)
Options: (options must be specified using the <key> or <key>=<value> syntax)
-all : [optional] Dump all objects, including unreachable objects (BOOLE
AN, false)
Was ist eine Oracle JDK/JRE Certified System Configuration?
Eine ideale, perfekt getestete und unterstützte Umgebung gilt als Oracle JDK/JRE Certified System Configuration. Das ist eine Kombination aus Betriebssystem mit installierte Service-Packs; das beschreibt das Unternehmen unter http://www.oracle.com/technetwork/java/javase/config-417990.html für Java 7. Bei gemeldete Bugs auf nicht zertifizierten Plattformen kann dann schnell ein „Sorry, das ist eine nicht-unterstützte Plattform, das schauen wir uns nicht weiter an“ folgen. Bei Linux ist zum Beispiel Ubuntu-Linux markiert als „Not certified on Oracle VM“. Das heißt nicht, dass es dort nicht zu 100% läuft, nur, dass im Fehlerfall eben kein Fix geben muss.
JavaScript, Rhino und Nashorn
Java ist zwar eine tolle Allround-Programmiersprache, aber die explizite Typisierung und der Zwang, Klassen und Methoden zu deklarieren, machen Java nicht wirklich attraktiv für Skripte, wo eher die Kompaktheit zählt und wo keine lang zu pflegenden Programme entstehen. Um die JVM und die Java-Bibliotheken auch zur Automatisierung von Abläufen einzusetzen, lässt sich neben der Java-Syntax auch alternative Programmiersprachen einsetzen.
JavaScript ist eine flexible interessante Programmiersprache, die mittlerweile auch außerhalb von Browsern populär ist, serverseitig eingesetzt wird und auch für die Entwicklung von Desktop-Anwendung – siehe Gnome 3, WinRT, Chrome Apps oder FirefoxOS.
Das Oracle JDK/OpenJDK bzw. das JRE[1] bringt ab Java 6 neben dem Java-Compiler eine JavaScript-Engine und ein Kommandozeilentool mit, das Sprite ausführt. So lässt sich JavaScript als alternative Programmiersprache einsetzen – die Sprache ist also auswechselbar und steht versinnbildlicht auf den Bibliotheken und der Laufzeitumgebung. Auch lässt sich die JavaScript-Umgebung in eigene Java-Programme einbetten und integrieren.
Die Java-Distribution liefert eine JavaScript-Engine aus, die sich allerdings von Java 6 auf Java 8 verändert hat.
· Java 6, Java 7: Rhino (https://developer.mozilla.org/en-US/docs/Rhino). Die JavaScript-Engine – in Java programmiert – kommt von Mozilla und basiert auf einer Implementierung von Netscape, die ihren Browser damals komplett in Java schreiben wollten. Die Browser-Implementierung „Javagator“ wurde zwar eingestellt, doch die JavaScript-Umgebung lebte weiter und Sun lizenzierte die Technologie und bettete sie (minimal verändert) in Java 6 und Java 7 ein.
· Ab Java 8: Nashorn (http://openjdk.java.net/projects/nashorn/, http://openjdk.java.net/jeps/174). Oracle entwickelte von Grund auf eine ganz neue JavaScript-Engine, die den Code ohne Interpretation direkt in Bytecode übersetzt und eine exzellente Performance und Kompatibilität mit ECMAScript-262 Edition 5.1 zeigt. Obwohl die JavaScript Edition 6 noch keine Rolle spielt, unterstützt Nashorn einige Spracherweiterungen, etwa Abkürzungen für Lambda-Ausdrücke. Da Nashorn nur JavaScript selbst unterstützt, Rhino aber noch einige Mozilla-Bibliotheken, kommt es zu Inkompatibilitäten, falls Nashorn unreines JavaScript ausführen soll.
[1] Bei anderen Java SE-Implementierungen muss das nicht zwingend gegeben sein.
Einmal Finalizer, vielleicht mehrmals die automatischen Speicherbereinigung
Objekte von Klassen, die eine finalize()-Methode besitzen, kann Oracles JVM nicht so schnell erzeugen und entfernen wie Klassen ohne finalize(). Das liegt auch daran, dass die automatische Speicherbereinigung vielleicht mehrmals laufen muss, um das Objekt zu löschen. Es gilt zwar, dass der Garbage-Collector aus dem Grund finalize() aufruft, weil das Objekt nicht mehr benötigt wird, es kann aber sein, dass die finalize()-Methode die this-Referenz nach außen gibt, sodass das Objekt wegen einer bestehenden Referenz nicht gelöscht werden kann und so zurück von den Toten geholt wird. Das Objekt wird zwar irgendwann entfernt, aber der Finalizer läuft nur einmal und nicht immer pro GC-Versuch. Einige Hintergründe erfährt der Leser unter http://www.iecc.com/gclist/GC-lang.html#Finalization.
Löst eine Anweisung in finalize() eine Ausnahme aus, so wird diese ignoriert. Das bedeutet aber, dass die Finalisierung des Objekts stehen bleibt. Die automatische Speicherbereinigung beeinflusst das in ihrer Arbeit aber nicht.
ThreadLocalRandom als schneller paralleler Zufallszahlengenerator
Zufallszahlen sind immer nur Pseudozufallszahlen und werden mit einer mathematischen Formel aus dem Vorgänger generiert. Der Vorgänger muss dabei gespeichert werden, und das ist die Aufgabe eines Random-Objekts. Die Methode Math.random() nutzt intern ein Random-Objekt, und jetzt kann es zu Wartezeiten kommen, wenn mehrere Threads gleichzeitig random() aufrufen, denn die Methode darf intern ja nur einen Thread die letzte Zufallszahl schreiben lassen. Math ist also eine Klasse mit Zustand und Zustandsverwaltung ist bei Multithreaded-Anwendungen immer etwas speziell.
Um Zufallszahlen schnell generieren zu können, sind diese Verzögerungen ungünstig, und es gibt zwei Lösungen dafür. Einmal lässt sich pro Thread ein Random-Objekt generieren, sodass es im Code der Random-Klasse dann keine Konkurrenzsituation geben kann. Aber optimal ist das noch nicht, denn der Programmcode der Random-Klasse ist auf diese Nebenläufigkeit vorbereitet, und bei nur einem Thread wäre ein schlankerer Programmcode besser, der für eine Single-Threaded Abarbeitung optimiert ist. Und hier kommt die Klasse java.util.concurrent.ThreadLocalRandom ins Spiel. Sie ist eine Unterklasse von Random und überschreibt die eigentliche Generator-Methode next(int)-Methode so, dass es keine Synchronisation gibt; die Ausführung in Multithreaded-Umgebung ist dementsprechend schnell.
Beispiel: Erzeuge Zufallszahlen zwischen 1 und 10:
ThreadLocalRandom threadLocalRandom = ThreadLocalRandom.current();
System.out.println( threadLocalRandom.nextInt( 1, 10 + 1 ) );
System.out.println( threadLocalRandom.nextInt( 1, 10 + 1 ) );
Die Variable threadLocalRandom kann problemlos zwischen verschiedenen Threads „geteilt“ werden.
Die Klasse ThreadLocalRandom erbt alle Methoden von Random, und überschreibt etwa die neuen Methoden aus Java 8, die einen Stream von Zufallszahlen liefern. Desweiteren kommen einige neue Methoden hinzu, um etwa Zufallszahlen in einem gewissen Bereich zu generieren – das fehlt in Random. Ein neuer Seed kann nicht gesetzt werden, ThreadLocalRandom überschreibt setSeed(long) so, dass eine UnsupportedOperationException ausgelöst wird.
class java.util.concurrent.ThreadLocalRandom
extends Random
§ static ThreadLocalRandom current()
Liefert das aktuelle ThreadLocalRandom-Objekt.
§ void setSeed(long seed)
Nicht unterstützt, löst UnsupportedOperationException aus.
§ double nextDouble(double n)
§ double nextDouble(double least, double bound)
§ double nextGaussian()
§ int nextInt(int least, int bound)
§ long nextLong(long n)
§ long nextLong(long least, long bound)
Liefert Zufallszahl und aktualisiert den Seed.
§ DoubleStream doubles()
§ IntStream ints()
§ LongStream longs()
§ DoubleStream gaussians()
Liefert einen Stream von Daten.
§ protected int next(int bits)
Liefert die nächste Zufallszahl, eine interne Methode, die ThreadLocalRandom aus Random überschreibt und protected belässt.