javablog.ch

Letzte Woche habe ich das SCJP 6 Upgrade Exam bestanden.

Folgende Bücher habe ich während der Vorbereitungsphase durchgearbeitet:

• Fast Track to Sun Certified Java Programmer (Scjp) 5.0 Upgrade Exam von Ka Iok Tong
• SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) von Kathy Sierra

Letzteres umfasst das komplette SCJP 5 und gibt Auskunft, welche Klassen und Methoden im Examen vorkommen können und welche nicht. Diese Hinweise vermisst man im “Fast Track to SCJP 5 Upgrade Exam” Buch. Hier wird beispielsweise die Klasse MessageFormat ausführlich beschrieben, obwohl sie für das Examen absolut irrelevant ist.

Bücher zum SCJP 6 gibt es noch keine, allerdings halten sich die Unterschiede zum SCJP 5 stark in Grenzen. Lediglich ein paar neue Klassen (NavigableMap, NavigableSet sowie Console) sind dazu gekommen.

Im Vergleich zum SCJP 1.4 sind die neuen Prüfungsthemen praxisbezogener. So wurden einige Klassen aus den Packages java.text und java.util.regex hinzugefügt. Als Konsequenz erhöht sich leider auch der Auswendiglern-Faktor (z.B. welche Konstruktor gibt es in der java.text.DateFormat Klasse ?)

Gleichzeitig wurden komplexe (aber dennoch spassige) Operatoren-Fragen wie Bitshifting oder Operatorvorrang gestrichen.

(heute wirds sehr technisch…)
Das Collection-Framework wurde im JDK6 unter anderem um das Interface NavigableMap erweitert.
NavigableMap leitet von SortedMap ab und bringt neue Zugriffsmöglichkeiten auf Keys und Entries. Beispielsweise gibt die Methode lowerEntry(K key) den nächst kleineren Eintrag zurück. Die Methode ceilingEntry(K key) ist da weniger restriktiv. Hier gilt: kleiner oder gleich.

Interessant ist noch, dass der Rückgabetyp von headMap(K key) und headMap(K key, boolean inclusive) sich unterscheidet. Beim ersteren gibts eine SortedMap zurück, beim anderen eine NavigableMap. Laut API liegt das daran, dass vorhandene Implementierungen von SortedMap einfach an NavigableMap angepasst werden können.

Dies gilt auch für tailMap und subMap Methoden.

Implementiert wird dieses Interface von der bisher bekannten TreeMap Klasse. Hier ein kleines Beispiel.

Eine der wesentlichen Neuerungen im JDK6 ist das “Attach on Demand”. Monitoringtools können sich zur Laufzeit mit einer JVM verbinden. Im JDK5 war das auch möglich, allerdings musste
die JVM vorher mit dem Parameter -Dcom.sun.management.jmxremote gestartet werden, was mit JDK6 nun nicht mehr notwendig ist.

Mit dem Tool “jconsole” stellt Sun bereits ein umfangreiches Diagnosetool zur Verfügung. Der Entwickler bzw. Administrator hat unter anderem die Übersicht über die Auslastung der einzelnen Speicherbereiche (”Eden Space”, “Survivor Space”, usw.) oder kann sich alle laufenden Threads mit ihren StackTraces ansehen.

Interessanterweise zeigt jconsole in der Prozessauswahl keine Prozesse an, die mit
lokalen Systemaccount gestartet worden sind. (Beispielweise ein als Service laufender Apache Tomcat).
Abhilfe schafft das Starten der jconsole über die Kommandozeile mit der Prozess-Id als Parameter.
Beispiel:

jconsole 4320

Weitere spannende Monitoringtools werden in diesem Artikel beschrieben.

Änderungen am Class-File Format:
Mustang bringt eine neue Form der Validierung von Klassen. Bisher wurden
Klassen vor der erstmaligen Ausführung in der VM mit einem zeit- und speicherintensiven
Verfahren verifiziert.
Die Verifizierung wird nun in zwei Phasen aufgeteilt: Beim Erzeugen der Klasse werden sogenannte “StackMap” Attribute gesetzt (Phase I), mit denen die Verifizierung zur Laufzeit (Phase II) wesentlich schneller ausgeführt werden kann. Ein StackMap Attribut beschreibt die möglichen Zustände des Stacks und der lokalen Variablen nach der Ausführung der Methode. Dieses Verfahren benötigt zum einen weniger Bytecode innerhalb der VM und zum anderen weniger Speicher im Verifizierungsprozess.

Diese neue Form der Validierung ist übrigens gar nicht so neu: Die Idee ist aus der J2ME-Spezifikation CLDC. Aufgrund der Speicher- und Resourcenbeschränkungen konnte die standardmässige Java-Verifizierung nicht im mobilen Umfeld eingesetzt werden, von daher musste ein neues Verfahren entwicklet werden, dass nun mit Mustang auch Einzug in die J2SE-Welt findet.

Allerdings birgt die Verifizierung über StackMaps auch potentielle Sicherheitslücken: Der polnische Sicherheitsexperte Adam Gowdiak konnte über die StackMap Attribute die Sandbox einer J2ME-VM umgehen und direkt auf native Methoden des Betriebssystems zugreifen. Siehe “Java 2 Micro Edition security vulnerabilities” (Achtung: PDF ist über 55MB gross!)

JDBC 4.0
Ganz im Zeichen des “Ease of Development” bringt die neue JDBC Version Annotations mit, die den Zugriff auf Tabellen vereinfachen sollen. Zudem werden auch weitere SQL Features (SQL ROWIDS, SQL/XML) unterstützt.

JAX-WS
Mustang bringt endlich die Webservices in das JDK. Unterstützt werden die neusten W3C und WS-I Standards (SOAP 1.2, WSDL 2.0 und WS-I Basic Profile 1.1). Wie bei JDBC 4.0 werden auch eigene Annotations mitgliefert, die einfachen Zugriff auf Webservices erlauben.

Attach-On-Demand
Dieses Feature erlaubt das Hinzufügen von Debugging, Profiling oder Monitoring-Tools zur Laufzeit und ohne vorherige Angabe von Startup Parametern. Das ist insbesondere für den Serverbereich interessant.

Mehr gibts im nächsten Teil…

Die JSR 270 ist eine sog. “Umbrella” JSR. Sie definiert nicht selbst die neuen Sprachfeatures von Java 6, sondern referenziert auf eine Sammlung von bestehenden JSRs. Momentan befindet sich JSR 270 im “Early Draft Review” Zustand, d.h. die Featureliste ist noch nicht fixiert. In dieser Postreihe möchte ich paar Features dennoch (ungruppiert) herausgreifen und kurz vorstellen:

GIF Image Writer:
Dank dem Verfall des GIF-Patents erlaubt das javax.imageio Package erlaubt nun auch das Erzeugen von GIF-Bildern. Meiner Meinung kommt das etwas zu spät, das GIF-Format hat in den letzten Jahren enorm an Bedeutung verloren.

Scripting for the Java Platform
Das neue Package javax.script definiert ein Framework zur Anbindung von externe Scriptsprachen. Das gabs bereits schon (z.B. Mozilla Rhino), allerdings eben noch nicht standartisiert.

Verbessertes Zugriff aufs Dateisystem
Bislang konnten Java-Entwickler nur beschränkt Informationen vom Dateisystem erhalten. Nun wird die java.io.File Klasse aufgebohrt, so dass z.B. auch der freie Speicherplatz ermittelt werden kann.

Mehr gibts im nächsten Teil…