Java 7 Compiler in Maven

Möchte man Java 7 in einem Maven Projekt verwenden muss man dem Maven Compiler Plugin das auch mitteilen. Eine Beispielkonfiguration gibts in diesem Artikel.

Lang ist’s her dass ich hier was technisches gebracht hab. Die Fotographie und einige private Dinge haben mich davon ab gehalten. Doch die Zeit der dürre ist vorbei, ich hab wieder begonnen meine Erfahrungen für den Blog festzuhalten :D

Möchte man Java 7 in einem Maven Projekt verwenden muss man dem Maven Compiler Plugin das auch mitteilen. Dieses würde atm. ansonsten versuchen das Projekt mit gutem alten Java 5 zu bauen.

Dazu muss das Plugin über folgende Angaben in der pom.xml umkonfiguriert werden:

<build>
    
    <plugins>
        
        <plugin>
            <groupid>org.apache.maven.plugins</groupid>
            <artifactid>maven-compiler-plugin</artifactid>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
                <showdeprecation>true</showdeprecation>
                <showwarnings>true</showwarnings>
                <executable>${env.JAVA_7_HOME}/bin/javac</executable>
                <fork>true</fork>
            </configuration>
        </plugin>
    </plugins>
</build>

Natürlich muss der Entwickler dafür die Umgebugnsvariable JAVA_7_HOME auf den Rootordner des JDKs der Version 7 linken.

Weitere Infos gibts auf der Seite des Maven Compiler Plugin. Unter Examples gibt es auch den Punkt “Compile Using A Different JDK” der die Vorgehenswiese dabei analog beschreibt. Dabei wird auch eine Möglichkeit aufgezeigt wie der Entwickler den Path JAVA_7_HOME in seiner Maven settings setzen kann.

Have Fun mit Java 7

Ähnliche Artikel:

Java 7 Tage Überblick – Was kommt dannach? Java 8

Java 7 haben wir in den vorherigen Blogeinträgen angesehen, was noch angedacht war und vielleicht bald in Java 8 zu sehen ist wird in diesem Artikel erläutert.

Ich weiß die Überschrift dieses Eintrags ist wenig kreativ, aber sein wir uns ehrlich, es war eh schon allen klar, nach der 7 kommt die 8. Chromo machts vor, auch Firefox steigt auf den Highway der Versionsnummernvergabe und nachdem Java nun 5 Jahre still stand möchte Oracle die Programmiersprache in einen Schnellzug verwandeln. Bereits Ende 2012 will man mit Java 8 JSRs nachreichen, die sich zeitlich nicht mehr in dieses Release unterbringen liesen.

Darunter fallen folgende JSRs:

  • JSR 294: Language and VM support for modular programming
  • JSR 308: Annotations on Java types
  • JSR TBD: Language support for collections
  • JSR TBD: Project Lambda
  • Modularization (Project Jigsaw)
  • JSR 296: Swing application framework
  • Swing JDatePicker component

Dabei ist ausdrücklich vermerkt, dass nicht alle der aufgeführten Punkte fix einen Platz in Java 8 haben werden. Was dabei auf uns zukommt sei nun kurz zu jedem der Punkte erklärt:

JSR 294: Language and VM support for modular programming

Der JSR 294 soll Sprach und VM Features beinhalten um modulares Programmieren zu ermöglichen/erleichtern indem es standardisierte Möglichkeiten für das Zugreifen auf Module bieten soll. Dies soll modularen Systemen wie OSGI und Jigsaw zugute kommen können. Nähere Detail unter http://jcp.org/en/jsr/detail?id=294 Ein guter Blog Eintrag der das den Bereich auf den JSR 294 abzielt erklärt ist auf blog.bjhargrave.com zu finden (in Englisch).

JSR 308: Annotations on Java types

Dieser JSR befasst isch mit einer Erweiterung der Verwendbarkeit von Annotationen. Bisher konnte man nur Packages, Typen, Methoden und Konstruktoren, Felder, lokale Variablen, Methodenparameter und Enumeratoren mit Annotationen versehen. Dies soll nun soweit erweitert werden, dass Annotationen überall dort Verwendung finden können, wo Typen erlaubt sind. Man kann nun zB dei Typangaben einer Map eine Annotation anhängen.

Map<@NunNull String, Integer> map;

Mehr dazu hier.

JSR TBD: Language support for collections

Dieser Teil wurde aus Project Coin herausgenommen und auf das nächste Release verschoben. Er beinhaltet eine erweiterte Sprachunterstützung für Collections, die dem Entwickler den Umgang damit erleichtern sollen. Wie die Implementierung dazu genau aussehen wird weiß ich noch nicht, ich möchte daher auf die Mailing Liste von Project Coin verweisen, wo man näheres in Erfahrung bringen könnte.

JSR TBD: Project Lambda

Vor einiger Zeit noch unter dem Namen „Closures“ wild diskutiert, versteckt sich hinter Project Lambda. Dahinter verbirgt sich die Möglichkeit Funktionsaufrufe als Parameter zu übergeben. Ein schnelles Beispiel, anstatt eine Runnable instanzieren zu müssen, soll man den inhalt der Runnable#run() Methode direkt übergeben können:

new Thread(#{System.out.println("Nullpointer!")}).start();

Dies ist ein stark vereinfachtes Beispiel, dass ich von folgendem Artikel aus jaxenter übernommen habe. Weitere Information gibts dort, oder aber direkt auf der Projekthomepage.

Modularization (Project Jigsaw)

Während JSR 294 für die Modularisierung unterstützend sein soll, wird in Project Jigsaw der Stier bei den Hörnern gepackt. Zwar kann man in Java aktuell Klassen zu Paketen zusammenfassen und hat damit einzeln gruppierte „Module“, doch es ist dabei nirgends definiert, was so ein Modul anderen Modulen an Funktionalität zur Verfügung stellt, welche es selbst benötigt, und in welchen Versionen. Letzteres ist zum Teil in Build Tools wie Maven abgebildet, jedoch kann lediglich eine Version des Jars eingebunden werden. Was wenn eine andere Bibliothek eine andere Version desselben Jar Files benötigt? Dieses Problem kann mit Project Jigsaw in Java 8 angegangen werden. Andere Lösungen wie z.B. OSGi (Open Service Gateway Initiative) wären ebenfalls eine Variante, Project Jigsaw soll jedoch mit dem JDK freihaus mitgeliefert werden.

JSR 296: Swing application framework

Hierzu habe ich leider nicht viel gefunden, die JSR Seite ist recht spärlich befüllt. Es soll erreicht werden, dass das Erstellen von Swing Anwendungen vereinfacht wird indem für Standardelemente ein Framework geschaffen wird, dass zB Startup, Shutdown, Resourcenmanagement oder Action- bzw. Session Statemanagement vereinfacht.

Swing JDatePicker component

Eigentlich sowas wie eine Standardkomponente, dennoch nicht im Java Core integriert, ein Date Picker! Zur Ehrenrettung von Java wurde in SwingX eine entsprechende Componente geschaffen, die bald ins Standardrepatoire übernommen werden könnte. Wie diese Komponente aussieht findet ihr hier und hier gibts die API dazu.

Nicht auf der Featureseite von Java 7 für kommende Versionen vermerkt, aber dennoch eine interessante und auch notwendige Neuerung die da bald kommen könnte:

JSR 310: Date and Time API

Ziel davon ist es eine neue simplere API zu schaffen um mit Zeiten und verschiedenen Daten umgehen zu können. Eine Referenzimplementierung dazu schafft das Sourceforge Projekt ThreeTen. Da das Projekt sich noch in der Alpha Phase befindet sei zumindest auf den UserGuide verwiesen, der die Funktionalität in grundzügen erklärt.

So, da darf man schonmal gespannt sein, doch bis es soweit ist, viel Spaß mit Java 7!

Ähnliche Artikel:

Java 7 Tage NIO.2 – Dateien und Verzeichnisse überwachen

NIO2 stellt eine Erweiterung der File API in der Java Welt dar. Was davon in Java 7 auf uns zukommt, und wie wie man damit Verzeichnisse überwacht steht hier.

Als letztes in der Java 7 NIO.2 Reihe möchte ich eine neue Möglichkeit vorstellen, wie man Dateiänderungen bzw Verzeichnisänderungen überwachen kann. Bisher war dies nur über Polling möglich. Man hat den Timestamp der Datei/des Verzeichnisses überwacht, das CRC verglichen oder ähnliches. Neu ist nun ein Service der einem diese Arbeit abnimmt:

Der neue WatchService dient dazu Objete die das Watchable Interface implementieren zu überwachen. Die neue Path Klasse ist bisher das einzige solche Objekt, doch ist der WatchService somit offen für eigene Implementierungen.

Am WatchService registrieren sich Watchable Objekte zur Überwachung mittels der register() Methode

WatchService watcher = FileSystems.getDefault().newWatchService();
Path p = new Path("/home/");
WatchKey key = p.register(watcher, ENTRY_CREATE);

dabei hat man die Möglichkeit die Events auf die geachtet werden soll per varargs Parameter zu deklarieren und kann aus folgenden wählen:

  • StandardWatchEventKinds.ENTRY_CREATE
  • StandardWatchEventKinds.ENTRY_MODIFY
  • StandardWatchEventKinds.ENTRY_DELETE

z.B. um alle arten zu überwachen

WatchKey key = p.register(watcher, ENTRY_CREATE, ENTRY_MODIFY, ENTRY_DELETE);

Nun kann man auf zwei Arten auf das Ergebnis des WatchServices zugreifen: take() oder poll()

take() – arbeitet blockierend und wartet darauf dass ein Event geworfen wird
poll() – liest direkt aus ob ein Event vorhanden ist. Findet der Aufruf kein solches liefert es null zurück. Es ist somit nicht blockierend.

Die beiden Methoden zum Abfragen nach Events liefern bei einem Treffer jeweils ein Ojekt vom Typ WatchKey zurück. Dieser kann einen oder mehrere WatchEvents beinhalten die man mittels pollEvents() Methode als List abrufen kann. Die Art des einzelnen WatchEvent kann mittels kind() Methode erfragt werden, während context() das auslösende Objekt zurückliefert. Im Falle eines überwachten Paths sollte hier stehts ein weiterer Path zurückgegeben werden.

while(true){
    WatchKey key = watcher.take();
    for(WatchEvent event : key.pollEvents()){
        if(event.kind() = ENTRY_CREATE){
            Path result = (Path)event.context();
            System.out.println(result.getName());
        }
    }
    key.reset();
}

Das WatchService implementiert Closable und AutoClosable und ist somit mit close() wieder schließbar bzw. erspart man sich das im neuen TryCatchblock.

key.reset(); ist notwendig um den Thread wieder freizugeben, denn der WatchService ist während des ganzen Aufrufes blockiert.

Happy NIOing :)

Ähnliche Artikel:

Java 7 Tage NIO.2 – Rekursiv durch einen Verzeichnisbaum

NIO2 stellt eine Erweiterung der File API in der Java Welt dar. Was davon in Java 7 auf uns zukommt, und wie mit NIO in einen Verzeichnisbaum gesucht wird hier

Es ist soweit, Oracle hat Java 7 veröffentlicht! Ebenfalls kurz und bündig auf java.net beworben, schon bereit zum Download. Laut Jaxenter inkludiert es 9.494 Bugfixes, 1.966 Überarbeitungen, 9.018 Changesets und 147 Builds. Die genauen Unterschiede zwischen diesen Begriffen bitte dort nachfragen, es klingt jedenfalls nach einer Menge Arbeit :) Das heißt nun könnt ihr auch direkt mit der neuen Version das hier gezeigte ausprobieren!

Darum gleich zurück zum heutigen Topic und ab durch den Verzeichnisbaum mit NIO2! Dazu werden in java.nio.Files zwei statische Methoden bereitgestellt:

java.nio.Files.walkFiletree(Path start, FileVisitor<? super Path> visitor);
java.nio.Files.walkFiletree(Path start, Set<FileVisitOption> options, int maxDepth, FileVisitor<? super Path> visitor);

Gleich mal zur Erklärung der Parameter:

start – Hier wird der Pfad übergeben der als Wurzelelement des Verzeichnisbaums dienen soll

options – Die FileVisitOption ist ein Enum und bietet Optionen in Bezug auf Symbolische Links(FOLLOW_LINKS) und Zyklenkennung (DETECT_CYCLES).

maxDepth – maximale Suchtiefe, also die Anzahl der Subverzeichnisse bis zu denen vorgegangen wird. Wäre maxDepth 3 und wir würden /home/nullpointer/1/2/3 von /home aus durchsuchen kämen wir also nur bis /home/nullpointer/1/2

visitor – Das FileVisitor Interface bietet dem Entwickler die Möglichkeit an diversen Punkten der rekursiven Suche einzuspringen. Bereits anhand der Namen der Methoden lässt sich zuordnen, wann dies geschieht:

FileVisitor.postVisitDirectory();
FileVisitor.preVisitDirectory();
FileVisitor.visitFile();
FileVisitor.visitFileFailed();

Diese Methoden liefern alle ein Ergebnis vom Typ FileVisitorResult zurück, mit dem bestimmt wird ob die Suche fortgesetzt wird oder nicht. Die möglichen Resultate sind: CONTINUE, SKIP_SIBLINGS, SKIP_SUBTREE, TERMINATE

Eine Implementierung des FileVisitors liefert Oracle gleich mit: SimpleFileVisitor. Dieser implementiert die oben angeführten Methoden Read-Only und wirft lediglich einen Fehler sollte eine Exception auftreten.

Happy NIOing bzw. FileVisiting :)

Ähnliche Artikel:

Java 7 Tage NIO.2 – DirectoryStream

NIO2 stellt eine Erweiterung der File API in der Java Welt dar. Was davon in Java 7 auf uns zukommt, und wie NIO2 den Verzeichnisinhalt ausliest gibts hier.

Heute gehen wir von den Java 7 Neuerungen im Bereich NIO weitere Methoden der Files Klasse an:

Path p = Paths.get(“c:/”);
DirectoryStream<Path> files = Files.newDirectoryStream(p);
try {
    for(Path fp : files)
        System.out.println(fp.getFileName());
} finally {
    files.close();
}

Mittel der Methode in Zeile 2 wird ein Stream geöffnet um alle Dateien und Verzeichnisse in einem gegebenen Pfad aufzulisten. Die zum Auslesen des Verzeichnisinhalts vorgesehene newDirectoryStream Methode ist in drei Ausprägungen vorhanden. Z.B. einen simplen Aufruf auf den Pfad wie im obrigen Beispiel. Auch gibt es eine Methode die diverse Filter annimmt, mit der man z.B. nach Dateigrößen aussortieren kann. Oder aber eine andere Ausprägung, bei der man mittels Regex Expression den Dateinamen filtern kann.

DirectoryStream implementiert das Interface Iterable und ist daher über foreach auslesbar. Da aber damit nicht alle auf einmal ausgelesen werden muss man den Stream wieder schließen. Da er das Closable Interface implementiert und damit auch AutoClosable kann der Stream innerhalb des neuen trycatch Mechanismus automatisch geschlossen werden wie vorherige Woche beschrieben.

Happy NIOing

Ähnliche Artikel: