• Unterstützt das Lesen von Bildern, die in einem JBIG2-Standard-konformen Verfahren, gemäß ITU T.88 und ISO/IEC 14492, kodiert wurden.
• Volle Unterstützung aller Merkmale, die im JBIG2-Standard definiert sind, einschließlich aller Kodierverfahren.
• Reiner Java Code
• Plugin für die Standard ImageIO API von Java.
• Sichere, robuste und qualitativ hochwertige Dekodierung.
• Hochoptimierte Geschwindigkeit.
• Unterstützt die Dekodierung eingebetteter JBIG2-Daten durch eigene DecodeParams, wie sie beispielsweise in PDF vorkommen können.

Mehr zu jbig2-imageio >

Zur Documentation Library >

BIRT besteht aus zwei Hauptkomponenten: Einem graphischen Berichte-Editor innerhalb der Eclipse IDE, um BIRT-Berichte zu designen, und einer Laufzeitkomponente für die Erzeugung von Berichten, die in jeder Java-Umgebung eingesetzt werden kann.

BIRT wird dazu eingesetzt, einen großen Bereich des Berichtwesens in typischen Applikationen in Unternehmen abzudecken.

Mit BIRT kann der Report im Eclipse Report Designer generiert werden. Es ist aber auch möglich, mithilfe des Web Based Report Designer einen Report zu erstellen. Die dritte Möglichkeit ist wohl die vielseitigste und interessanteste: der Custom Report Designer. Dazu werden dem Entwickler die einzelnen Klassen der Engine, beziehungsweise diese als Ganzes (API), zur Verfügung gestellt und somit kann er einen eigenen Report Designer generieren.

Einzelne Komponenten von BIRT

Report Design Engine
Die Report Design Engine generiert aus den Eingabedaten eine XML-Datei, welche das Design, die Datenherkunft sowie die verschiedenen Parameter des Reports beschreibt.

Charting Engine
Die Charting Engine wird von der Report Engine dann aufgerufen, wenn ein Diagramm (engl. Chart) erstellt werden muss. Daten werden von der aufrufenden Report Engine bereitgestellt.

Report Engine
Die Report Engine ist in zwei Bereiche mit unterschiedlichen Services untergliedert: Der erste Bereich, die sogenannten Generation Services, kümmern sich um die Beschaffung der Daten. Er gibt eine Art Rohdokument an die Presentation Services weiter, welche die Aufbereitung in ein Ausgabeformat (zum Beispiel PDF o.ä.) übernehmen.

Typische BIRT-Anwendung
In einer typischen Anwendung wird BIRT zur Generierung von Tabellen-basierten Reports, welche in einem leicht austauschbaren Format (PDF) erstellt werden, verwendet. Dazu wird BIRT aus einer JAVA-Anwendung aufgerufen und es werden POJOs bereitgestellt, um die Daten in der gewünschten Form präsentieren zu können. Als Datenquelle ist POJOs (Plain Old Java Object) gewählt worden, da diese eine größtmögliche Flexibilität ermöglichen. Hier gibt es einige Tricks und Kniffe zu beachten.

Für den Aufruf der verschiedenen Komponenten von BIRT, welche zu konfigurieren sind, findet man sehr viele Beispiele im Internet. Hier nur ein paar Auszüge:

config = new EngineConfig();
config.setBIRTHome(file.getAbsolutePath());
  ⋮
Platform.startup(config);
logger.debug(„Platform created, starting factory.“;
IreportEngineFactory factory = (IReportEngineFactory) Platform
.createFactoryObject(IReportEngineFactory.EXTENSION_REPORT_ENGINE_FACTORY);
engine = factory.createReportEngine(config);
  ⋮
design = engine.openReportDesign(name_rtpdesign_File);
  ⋮
IRunAndRenderTask task = engine.createRunAndRenderTask(design);
  ⋮
PDFRenderOption options = new PDFRenderOption();
  ⋮
task.setRenderOption(options);
  ⋮
try {
  task.run();
} catch (EngineException e) {
  throw (new, e);
}
engine.destroy();
task.close();

Dieser Code (und noch ein paar andere Zeilen) wird verwendet, um einen BIRT zu konfigurieren und einen Report zu produzieren.

Einer der wichtigsten Tricks ist, dass beim Beenden des (eigenen) Programms unmittelbar ein Plattform.shutdown() aufgerufen wird. Nach diesem Aufruf kann jedoch kein Bericht mehr erstellt werden. Deshalb soll man sie auch z.B. beim Schließen des Fensters aufrufen.

Im Folgenden werden die Klassen Job4BirtFactory, Job4Birt und History4Birt verwendet. Die Factory Klasse ist hierbei die Klasse, welche über eine Methode (getJob()) die beiden weiteren Klassen mit Daten füllt. Die beiden anderen Klassen fungieren hier als „Datenträger“ und bestehen größtenteils aus Gettern, Settern und Variablen.

Die Schnittstelle in BIRT wird über eine „scripted Datasource“ erstellt.

Hier ist das Script zu sehen, welches die Job4BirtFactory (aus dem Report) aufruft und über diesen Weg den Job (für welchen das Script die Job ID bereithält) erhält.

Nun können von dieser DataSource DataSets erstellt werden, welche wie Tabellen funktionieren. Achtung: 2 Scripts müssen erstellt werden!
Eines zum Öffnen der Datenquelle (open) -

das andere Script zur detaillierten Auswertung der Daten eines POJO (hier exemplarisch an der History dargestellt). Das Fetch-Script kann ähnlich einer While-Schleife verwendet werden.

Wir arbeiten daher an einer Möglichkeit, um den aktuellen Zustand der jadice document platform und deren Module und Komponenten mittels JMX zu propagieren. Derzeit sind wir in der Proof-Of-Concept Phase und möchten die bisherige Idee vorstellen.
Um das Exponieren von Informationen über die jadice document platform einfach und flexibel zu gestalten, arbeiten wir an einer Pseudo-DSL (=Domain Specific Language), die möglichst aussagekräftig beschreiben soll, welche Daten exponiert werden und zusätzlich die JMX API deutlich vereinfachen:

Viewer v = //...
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer()
ManagementConfiguration.on(mbs)
	.addModule(SupportUtilsManagementModule.get())
	.addModule(ViewerManagementModule.manage(v,"MyViewer"))
	.start();

Die Management Logik wird hierbei in Module gruppiert. Jedes dieser Module kann ein oder mehrere MBeans einem MBeanServer zuweisen. Das ViewerManagementModule beispielsweise erzeugt ein MBean mit lesendem und teilweise schreibendem Zugriff auf einige Properties des Viewer. So ist es beispielsweise möglich, den aktuellen Zoom-Faktor über eine JMX Console zu ändern.
Wie bereits erwähnt, befindet sich diese Management-Erweiterung in einem Proof-Of-Concept Stadium. Für Ideen, Anforderungen oder auch einfach nur Lob sind wir jederzeit offen.

TextFormatInfo tfi = new TextFormatInfo();
tfi.setEncoding("UTF-8");	
Document doc = loader.loadDocument(is, tfi,0);

Um das Beispiel möglichst einfach zu halten, wurde auf die Behandlung von möglichen Fehlern verzichtet.
In diesem Beispiel wird eine Instanz der Klasse TextFormatInfo erzeugt und das Encoding auf UTF-8 gesetzt. Möglich sind viele weitere Encodings, eingeschränkt lediglich durch die Möglichkeiten des Java java.nio.charset.Charset.

Ist der Name eines bestimmten Encodings nicht bekannt oder unklar, ob dieses der Java VM zur Verfügung steht, kann über folgendes Beispiel eine Liste aller möglichen Charset Namen und deren Aliase erzeugt werden:

SortedMap<String, Charset> m = Charset.availableCharsets();
for (Entry<String, Charset> e : m.entrySet()) {
    Charset charset = e.getValue();
    System.err.println(charset.name());
    Set<String> aliases = charset.aliases();
    for (String alias : aliases) {
        System.err.println("\t"+alias);
    }
}

Neben dem Setzen eines Encodings für das Laden von Textdokumenten, bietet die Klasse TextFormatInfo auch eine Reihe weiterer Konfigurationsmöglichkeiten wie beispielsweise das Setzen einer Schrift, mit deren Hilfe die Texte angezeigt werden sollen. Weitere Details und Tipps hierzu werden in einen zukünftigen Artikel einfließen.

Node-Klasse
Die neu zu erstellende Nodeklasse muss von der abstrakten Superklasse com.levigo.jadice.server.Node erben. Dabei ist zunächst nur die abstrakte Methode getNodeClassName() zu implementieren. Als Rückgabewert hat diese den voll qualifizierten Klassennamen der korrespondierenden Workerklasse zu liefern:

package com.myCompany.jadice.client;
import com.levigo.jadice.server.Node;

public class DemoNode extends Node {
  public String getNodeClassName() {
    // Klassenname der Workerklasse aus Bsp unten
    return "com.myCompany.jadice.worker.DemoWorker";
  }
}

Soll es möglich sein, dass dem Worker zur Laufzeit Parameter übermittelt werden, so kann dies durch weitere Methoden in der Node-Implementierung erfolgen. Dabei ist zu beachten, dass alle Objekt- und statischen Attribute das Interface Serializable implementieren müssen, da diese über JMS serialisiert und transportiert werden.

public String getMyParameter() {
    // Sollte z.B. über Setter-Methode gesetzt werden
    return "a Parameter";
  }

Der selbst implementierte Node muss sowohl client- als auch serverseitig im Klassenpfad eingebunden werden und kann später in eigene Workflows eingebettet werden.

Worker-Klasse
Die Workerklasse, in der die Konvertierung durchgeführt wird, erbt von der abstrakten, generischen Superklasse com.levigo.jadice.server.core.NodeWorker<N>, wobei der Typ-Parameter <N> für die zugehörige Node-Klasse steht.
Hier ist die abstrakte Methode work() zu implementieren, in der die serverseitige Konvertierung durchführt wird.

package com.myCompany.jadice.server;

// Hier nur die wichtigen Imports
import com.levigo.jadice.server.core.NodeWorker;
import com.myCompany.jadice.client.DemoNode;

public class DemoWorker extends NodeWorker<DemoNode> {

  protected void work() throws Throwable {
    // Im Bsp oben definierter Parameter
    String myParam = getNode().getMyParameter();

    // Abholen der Eingabedaten
    for (Stream stream : getInputBundle()) {
      InputStream unprocessedIS = stream.getInputStream();
      // Metadaten des empfangenen Datenstrom
      StreamDescriptor unprocessedSD = stream.getDescriptor();

      // Methode, die den Datenstrom verarbeitet
      // (nicht im Listing gezeigt)
      InputStream processedIS =  process(unprocessedIS, myParam);

      // Metadaten des verarbeiten Datenstroms
      // unprocessedSD wird als „Parent" gesetzt
      StreamDescriptor processedSD = new StreamDescriptor(unprocessedSD);
      processedSD.setDescription("<Beschreibung>");
      processedSD.setMimeType("<MIME Type>");
      processedSD.setFileName("<Dateiname>");

      // Verknüpfen von Ergebnis und Metadaten
      Stream result = new BundledStream(processedIS, processedSD);
      // Weitergabe des Ergebnisses
      getOutputBundle().addStream(result);
    }
}

Der auf diese Weise implementierte Worker muss nur im Klassenpfad des jadice servers eingebunden werden und wird bei Verwendung des zugehörigen Nodes aus dem vorherigen Abschnitt automatisch aufgerufen.

Beispiel eMail-Konvertierung
Der jadice Server untersucht und durchleuchtet die eMail auf deren Inhalt und leitet die weiteren Schritte ein. Eine eMail kann dabei sehr komplex strukturiert sein und unter Umständen neben dem reinen eMail-Text auch mehrere Anhänge mit weiteren Dokumenten unterschiedlicher Formate enthalten. Diese Anhänge müssen erkannt, entschlüsselt, ausgepackt und aufbereitet werden, ohne dass wichtige Informationen wie Metadaten verloren gehen.
Erkennt der jadice Server beispielsweise ein ZIP-Dokument als Anhang, so leitet er automatisch eine Extraktion der enthaltenen Dokumente ein, welche dann erneut untersucht werden. Dies können Word-Dokumente mit zusätzlichen OLE und XLS-Informationen sein.
Ziel einer Konvertierung ist es nun, all diese Informationen über Dateiinhalte und Dateianhänge zu bewahren. Das heisst, die Software muss Datenblätter erstellen können, die sowohl Aufschluss über die Struktur der Ursprungsdatei geben können als auch über die Metadaten der enthalten Dokumente, wie Änderungsdatum, Ersteller und dergleichen. Dies geschieht in einzelnen, automatisch ablaufenden Konvertierungsstufen, die kaskadiert ausgeführt werden. Am Ende der Konvertierung sollte ein Dokument vorliegen, das alle Informationen des Ursprungsdokuments in geordneter und übersichtlicher Form wiedergibt.

Eine Konvertierungssoftware muss also folgende Anforderungen erfüllen:

• Dynamisches System, das den Einbau zusätzlicher Konvertierungsstufen ermöglicht.
• Automatische Erfassung, Erkennung, Voranalyse und Formatierung der Eingangsdokumente ohne Qualitäts- und Informationsverlust.
• Erstellung von Datenblättern, die Aufschluss über Status- und Metadaten liefern.
• Erstellung von Inhaltsverzeichnis und Trennblättern, die Informationen über Struktur und Inhalt der einzelnen Dateielemente beinhalten.

Der jadice Server erfüllt diese Anforderungen problemlos und bleibt darüber hinaus flexibel, da neue Formate einfach über Drittanwendungen eingebunden werden können. Zudem führt er durch eine Fremdkomponente nach Abschluss der Formatierung eine Qualitätsvalidierung durch.

Siehe auch Technische Informationen.

Trau dem Task-Manager nicht ...

Die Versuchung liegt nahe, dabei zunächst auf Betriebssystem-Tools (wie den Windows Task-Manager) zurückzugreifen. Aber Achtung: die dort gemeldete Speicherauslastung entspricht mitnichten dem tatsächlichen Speicherverbrauch der JVM, denn:

• Im Task-Manager wird der Speicherverbrauch des JAVA-Prozesses angezeigt und nicht der JAVA Heap Size, der eigentlich interessiert, weil dies der durch die Anwendung verbrauchte Speicher ist. Neben dem JAVA Heap Size benötigt der Prozess weiteren Speicher für die JVM und deren Datenstrukturen.
• Im Task-Manager wird häufig nicht der von der JVM tatsächlich verwendete Speicher dargestellt. Gibt die JVM in Zuge ihrer Garbage Collection Speicher frei, so wird dies von der JVM nicht zwangsläufig an das Betriebssystem propagiert. Im Task-Manager wird also ein viel höherer Wert angezeigt als der JAVA Heap tatsächlich einnimmt. Folge: Als Beobachter hat man den Eindruck, als ob die JAVA-Anwendung ständig „am Anschlag" arbeitet, obwohl der Anwendung noch massig Speicher zur Verfügung steht.

... sondern lieber den JAVA-Bordmitteln

Deshalb kann ein zuverlässiges Speicher-Monitoring nur mit Werkzeugen erfolgen, die exakte Werte für den JAVA Heap Size bzw. dessen einzelne Speicherbereiche (Eden Space, Survivor Space...) liefern. Ein ideales Tool ist die JConsole, die seit JAVA 5 zum Lieferumfang des JDK gehört (zu finden im Verzeichnis JDK_HOME/bin).

Musste unter JAVA 5 die Verwendung der JConsole beim Starten der Anwendung über die Kommandozeile mit dem Parameter -Dcom.sun.management.jmxremote noch explizit ermöglicht werden (Starten des JMX Agent), ist seit JAVA 6 ein unmittelbares Verbinden der JConsole auf den JAVA-Prozess möglich. Hierzu wird jconsole.exe aufgerufen und auf eine lokale oder eine Remote-Anwendung verbunden.

Neben der Auslastung der einzelnen Speicherbereiche (Heap und Non-Heap) lassen sich über die JConsole weitere Kenngrößen verfolgen (z.B. Threads). Sägezahnförmige Verläufe der Speicherauslastungen lassen erkennen, dass bei der Garbage Collection jeweils wieder ausreichend Speicher freigegeben wird und z.B. kein Memory Leak in der Applikation vorliegt. Auch eine Detailanalyse der einzelnen Memory Pools und deren Tuning über JVM Optionen wird damit möglich.

Alternativ kann zur Analyse auch VisualVM eingesetzt werden. VisualVM wird seit JAVA 6 Update 7 als Bestandteil des JDK mit ausgeliefert - es vereint einige der bisherigen JDK-eigenen Werkzeuge unter einer modernen, Netbeans-basierten Oberfläche. Die analysierten Anwendungen können dabei auch in älteren Umgebungen laufen - die zur Überwachung des Speicherverbrauchs erforderliche Monitoring-Funktionalität wird beispielsweise bereits ab JAVA 1.4.2 unterstützt. Der volle Funktionsumfang ist jedoch erst gegeben, wenn die Anwendung in einer JAVA 6-Umgebung abläuft.

Referenzen
http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html
https://visualvm.dev.java.net/

HPROF-Dateien
Dort kann man über die JVM-Option -XX:+HeapDumpOnOutOfMemoryError erzwingen, dass in einer OutOfMemory-Situation ein binärer Dump des Speicherinhalts in eine HPROF-Datei (Dateiname   "java_pidXXXX.hprof") geschrieben wird. Unterstützt wird dieses Feature in Java 6 sowie ab 5.0u7, in Java 1.4 nur bedingt. HPROF-Dumps sind plattformunabhängig und können recht groß werden (entsprechend dem Speicherverbrauch der JVM zum Zeitpunkt des Snapshots).

Vorteil: Exakt zum Fehlerzeitpunkt wird ein Dump geschrieben, der sich anschließend auswerten lässt. Insbesondere bei Server-basierten Anwendungen kann dies sehr hilfreich sein, um Memory Leaks von einem schlichtweg zu klein konfigurierten Java Heap zu unterscheiden.
Über das Kommandozeilen-Tool jmap (sowie 5 und 6) kann außerdem zu einem beliebigen Zeitpunkt ein Memory Snapshot einer laufenden JVM angefordert werden (jmap -dump:file=path_to_file java_pid).

Analyse
Zur Analyse der HPROF-Dateien kommt mit Java 6 das Utility jhat mit (Aufruf: jhat java_pidXXXX .hprof). Bei großen Dumps wirkt jhat allerdings überfordert. Sehr gute Erfahrungen konnten hingegen mit YourKit als kommerziellem Profiler gemacht werden, der das Laden von HPROF-Snapshots unterstützt. Die Darstellung der Objekte und der von diesen belegte Speicher entspricht der gewohnten Ansicht einer Profiling-Session, so dass die Ursachenfindung in gewohnter Weise erfolgen kann.

Windows bietet die Möglichkeit, eigene URL Handler für Protokolle zu definieren. Dies wird unter http://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx sehr gut beschrieben. Benötigt werden zwei Dinge: Ein Eintrag in der Windows Registry und eine Anwendung, die eine entsprechende Anfrage behandeln soll. Möchte man ein JadicePanel für die Anzeige von Dokumenten nutzen, kann beispielsweise das Protokoll „jadvwr" definiert werden. Wird eine URL mit dem Protokoll Prefix jadvwr: angefordert, wird die Anfrage an die dafür registrierte Anwendung weitergereicht. Für die Konfiguration kann ein Registry Eintrag ähnlich dem folgenden verwendet werden:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\jadvwr]
@="URL:Jadice Viewing Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\jadvwr\shell]

[HKEY_CLASSES_ROOT\jadvwr\shell\open]

[HKEY_CLASSES_ROOT\jadvwr\shell\open\command]
@="\"E:\\IEUrlHandler\\view.bat\" \"%1\""

Hierbei wird angenommen, dass das Batch-Script E:\IEUrlHandler\viwer.bat existiert. Dieses könnte in etwa wie folgt aussehen:

set WD=%~dp0
java -cp %WD%jadice-documentplatform-4.1.0.9-all.jar;%WD%bin/ Startup %1
set WD=

Dieses Script leitet den Aufruf lediglich an eine Java Applikation weiter. Hierbei ist die Zielapplikation ein Wrapper um das JadicePanel, welcher die angeforderte URL nimmt und die Daten mittels Java API auf den Client zieht und zur Anzeige bringt:

 import java.io.File;
 import java.io.FileOutputStream;
 import java.io.IOException;
 import java.io.InputStream;
 import java.net.URL;
 
 public class Startup {
   public static void main(String[] args) throws Throwable {
     
     // url prefix jadvwr: entfernen
     String url = args[0].substring(7);
     InputStream is = new URL(url).openStream();
     File f = File.createTempFile("jad-url-handler", "tmpdoc");
     writeToFile(is, f);
     
     String openTarget = "-open=" + f.getAbsolutePath();
     JadicePanel.main(new String[]{openTarget});
   }
   
   private static void writeToFile(InputStream is, File f)
     throws IOException {
     FileOutputStream out = new FileOutputStream(f);
     byte[] buf = new byte[2048];
     int read;
     
     while ((read = is.read(buf)) > -1) {
       out.write(buf, 0, read);
     }
     out.flush();
     out.close();
   }
 }

Der hier gewählte Weg eines Wrappers um die Klasse JadicePanel ist lediglich ein Beispiel, um die Logik möglichst einfach darzustellen. Entscheidend sind bei diesem Vorgehen zwei Dinge: Der erste Parameter, welcher der Anwendung übergeben wird, ist die URL, die angefordert wurde. Diese enthält noch das Protokoll jadvwr:, welches für die weitere Verarbeitung entfernt wird.
Die zweite wichtige Eigenschaft (oder vielmehr Annahme) ist, dass der Rest der URL in einer Art und Weise zur Verfügung steht, die die Java API verarbeiten kann. Es wird über URL.openStream() ein InputStream zum Dokument erfragt und die Daten daraus in eine temporäre Datei geschrieben.
Die temporäre Datei wird dann als Parameter an JadicePanel.main(String[]) weitergereicht.

Mit diesem einfachen Beispiel ist es möglich in Webanwendungen URLs, ähnlich der folgenden, zu integrieren:

jadvwr:http://host.company.com/documentstore/some-document.pdf

Der Vorteil dieser Methode ist, dass der Umgang mit der JavaVM und auch der Umgang mit Browser-Eigenheiten deutlich gemindert wird. Nachteilig ist wiederum die Notwendigkeit eine Anwendung auf alle Arbeitsstationen auszurollen.

com.levigo.jadice.addon.search.SearchRequest

Mittels des

SearchRequest

wird die Suchanfrage konfiguriert und letztlich auch ausgeführt.

Beispiel:
Möchte man die Seiten eines geladenen Dokuments nach dem String „java" durchsuchen, so genügt bereits folgendes Code-Fragment:

SearchRequest request = new SearchRequest();
request.setPages(document.getPages());
request.setSearchStrings(new String[]{"java"});
request.addSearchResultListener(new MyListener());
request.execute();

Die Methode setSearchStrings erlaubt es, mehrere Strings für eine Suche zu setzen. Es ist zu beachten, dass diese in einer „ODER"-Relation zueinander stehen. Die Suche wird jeden Treffer melden, der einen der angegebenen Strings enthält.
Die Method execute() führt die Suchanfrage letztlich aus. Wichtig sind hierbei zwei Dinge:

• execute() wird asynchron ausgeführt. Die Anfrage wird an die jadice interne SearchEngine weitergereicht und in einem eigenen Thread bearbeitet.
• Es kann derzeit nur eine Suche zur selben Zeit ausgeführt werden. Wird die Methode execute() gerufen, während noch eine weitere Suche läuft, wird die laufende Suchanfrage abgebrochen.

Um die Ergebnisse der Suche zu erhalten wird eine Implementation des com.levigo.jadice.addon.search.SearchResultListener registiert. Dieser wird über jeden Treffer informiert. Eine Implementation könnte beispielsweise wie folgt aussehen:

public class MyListener implements SearchResultListener {
    public void searchResultFound(SearchResultEvent e) {
        Result result = e.getResult();
        Page page = result.getPage();
        String text = result.getSelectedText();
        // page und text verarbeiten
    }
}

Das SearchRequest verfügt über weitere kleine Helfer, die vor allem für die Verwendung innerhalb einer Suchmaske von Interesse sind. Mehr Informationen hierzu wird der zweite Teil dieser Artikel-Reihe „enthüllen".

Der beste Startpunkt für ein Verständnis dessen, was die document platform bietet, stellt die documentation.html dar. Diese enthält eine Reihe von Informationen zu technischen und auch organisatorischen Themen, wie etwa der Struktur der Auslieferung. Über den Link „Distribution Overview" ist eine Übersicht über die gesamte Auslieferung erhältlich, welche die einzelnen Verzeichnisse und deren Inhalte beschreibt. Die Änderungen, die an den einzelnen Versionen vorgenommen wurden sind unter „Release notes" zu finden. Hier wird aufgelistet welche Änderungen und Erweiterungen eingeflossen sind und welche evtl. entfernt wurden.

Innerhalb einer IDE, wie beispielsweise Eclipse, ist eine Analyse verhältnismäßig einfach. Problematisch wird es jedoch, wenn die Probleme außerhalb der IDE auftauchen und ein Remote-Debugging nicht möglich ist.

Die JavaVM bietet für diese Fälle einen einfachen Weg den aktuellen Zustand aller Threads in einem Stack-Trace ähnlichen Format auszugeben: dem so genannten Thread Dump. Dieser kann über zwei Wege erstellt werden:

• STRG + PAUSE: Wird diese Tastenkombination in einem Java Konsolen-Fenster betätigt, erstellt die JavaVM einen Thread Dump und gibt diesen auf der Konsole aus. Der Vorteil dieser Variante ist, dass keine zusätzlichen Werkzeuge benötigt werden. Ein Thread Dump ist somit sehr einfach zu erstellen.
• Mittels der Tools jps und jstack (zu finden im Verzeichnis jdk-home/bin): Leider steht das Tool jstack unter Windows erst mit JDK 1.6 zur Verfügung. Unter Linux ist es bereits im JDK 1.5 enthalten. Bei der Ausführung von jps werden die PIDs (Process-IDs) aller laufenden Java-Anwendungen ausgegeben. Startet man nun jstack mit der PID des zu untersuchenden Prozesses, gibt das Kommando den Thread Dump auf der Standard-Ausgabe aus. Der Vorteil bei der Nutzung von jstack ist, dass hier nun der Thread Dump ausgegeben wird. Somit können sich keine konkurrierenden Ausgaben auf System.out "dazwischen mogeln".

Prinzipiell handelt es sich bei Thread Dumps um ein ASCII basiertes Format. Für eine komfortable Betrachtung sei aber auf das Werkzeug TDA verwiesen, welches die Daten in einem strukturierten UI zur Verfügung stellt.