14.4 Auslieferung von Java-Programmen
14.4.1 Weitergabe des Bytecodes
Direkte Weitergabe der Klassendateien
Der ausführbare Programmcode einer Java-Applikation befindet
sich in den vom Compiler erzeugten .class-Dateien.
Sie sind der wichtigste Bestandteil bei der Auslieferung eines Java-Programms.
Wir werden uns in diesem Abschnitt ansehen, auf welche Weise die Klassendateien
weitergegeben werden können und was dabei zu beachten ist. Neben
den Klassendateien müssen mitunter auch zusätzliche Dateien
mit Übersetzungstexten, Fehlermeldungen, Icons oder Bilddateien
weitergegeben werden. Wie diese zusammen mit den Klassendateien ausgeliefert
und verwendet werden können, zeigt der nächste Abschnitt.
Die einfachste Möglichkeit, ein Java-Programm auszuliefern, besteht
darin, die Klassendateien so zu belassen, wie sie sind, und sie entsprechend
ihrer Paketstruktur auf das Zielsystem zu kopieren. Das Programm kann
dann auf dem Zielsystem gestartet werden, indem der Java-Interpreter
aus dem Installationsverzeichnis aufgerufen und der Name der zu startenden
Klasse als Argument angegeben wird.
Als Beispiel wollen wir uns eine hypothetische Applikation ansehen,
die aus folgenden Klassen besteht:
com.gkrueger.app.App
com.gkrueger.app.AppFrame
com.gkrueger.util.Logger
Die Klassen App und AppFrame
befinden sich im Paket com.gkrueger.app
und die Klasse Logger im Paket
com.gkrueger.util. Ausgehend
vom Basisverzeichnis, liegen die Klassendateien also in den Unterverzeichnissen
com\gkrueger\app und com\gkrueger\util.
Die main-Methode
befindet sich in der Klasse App.
Soll das Programm auf dem Zielsystem beispielsweise im Verzeichnis
c:\gkapp installiert werden, müssen
die drei Dateien wie folgt kopiert werden:
- App.class nach c:\gkapp\com\gkrueger\app
- AppFrame.class nach c:\gkapp\com\gkrueger\app
- Logger.class nach c:\gkapp\com\gkrueger\util
Das Programm kann dann aus dem Installationsverzeichnis c:\gkapp
durch Angabe des qualifizierten Klassennamens gestartet werden:
java com.gkrueger.app.App
Voraussetzung zum Starten der Applikation ist, dass der Klassenpfad
korrekt gesetzt ist. Soll das Programm stets aus dem Installationsverzeichnis
heraus gestartet werden, muss das aktuelle Verzeichnis ».«
im CLASSPATH
enthalten sein (alternativ kann seit dem JDK 1.2 auch gar kein Klassenpfad
gesetzt sein). Soll das Programm von beliebiger Stelle aus gestartet
werden können, muss der Pfad des Installationsverzeichnisses
c:\gkapp in den Klassenpfad aufgenommen
werden. Dazu kann entweder die Umgebungsvariable CLASSPATH
modifiziert oder der gewünschte Klassenpfad mit einer der Optionen
-cp
oder -classpath
an den Java-Interpreter übergeben werden. Dafür wäre
beispielsweise folgender Aufruf geeignet:
java -cp c:\gkapp com.gkrueger.app.App
Verwendung eines jar-Archivs
Noch einfacher wird die Installation, wenn anstelle der verschiedenen
Klassendateien eine einzelne jar-Datei ausgeliefert wird. Auf dem
Zielsystem spielt es dann keine Rolle mehr, aus welchem Verzeichnis
heraus die Applikation aufgerufen wird und wie die CLASSPATH-Variable
gesetzt ist. Weitere Hinweise zur Anwendung des jar-Programms finden
sich in Abschnitt 53.6. Dort
wird auch erläutert, wie Applets in jar-Dateien ausgeliefert
werden können.
Angenommen, das Basisverzeichnis für die Programmentwicklung
auf der Quellmaschine ist c:\prog\java
und die Klassendateien liegen in den Verzeichnissen c:\prog\java\com\gkrueger\app
und c:\prog\java\com\gkrueger\util. Um
eine jar-Datei zu unserem Beispielprojekt zu erstellen, ist aus dem
Entwicklungsverzeichnis c:\prog\java
heraus folgendes jar-Kommando
abzusetzen:
jar cvf myapp.jar com
Dadurch werden alle Dateien aus dem Unterverzeichnis com
und allen darin enthaltenen Unterverzeichnissen unter Beibehaltung
der Verzeichnishierarchie in die jar-Datei myapp.jar
kopiert. Um das Programm auf der Zielmaschine aufzurufen, reicht es
aus, myapp.jar an eine beliebige Stelle
zu kopieren und den Java-Interpreter wie folgt zu starten:
java -cp myapp.jar com.gkrueger.app.App
Anstelle des Unterverzeichnisses mit den Klassendateien haben wir
nun die jar-Datei im Klassenpfad angegeben. Für den Interpreter
sind beide Varianten gleichwertig und er wird das Programm in der
gleichen Weise wie zuvor starten. Vorteilhaft an dieser Vorgehensweise
ist, dass auf der Zielmaschine nur noch eine einzige Datei benötigt
wird und nicht mehr ein ganzes System von Verzeichnissen und Unterverzeichnissen
wie zuvor. Das vereinfacht nicht nur die Installation, sondern erhöht
auch ihre Haltbarkeit, denn einzelne Dateien können nicht mehr
überschrieben werden oder verlorengehen.
Ausführbare jar-Archive
Wir können sogar noch einen Schritt weitergehen und die jar-Datei
selbst »ausführbar« machen. Dazu müssen wir eine
Manifest-Datei erstellen, in der der
Name der Klasse angegeben wird, die die main-Methode
enthält. Anschließend lässt sich die jar-Datei mit
der Option -jar
des Interpreters ohne explizite Angabe der Hauptklasse starten.
Wir erstellen also zunächst eine Textdatei manifest.txt
mit folgendem Inhalt (bitte mit einer Zeilenschaltung abschließen,
sonst wird die Manifest-Datei nicht korrekt erstellt):
Main-Class: com.gkrueger.app.App
Nun kann das jar-Archiv erzeugt und die Manifest-Datei einbezogen
werden:
jar cvfm myapp.jar manifest.txt com
Dieses Archiv kann nun mit Hilfe der Option -jar
ohne Angabe des Klassennamens gestartet werden:
java -jar myapp.jar
Auch jetzt verhält sich das Programm genauso wie in den beiden
zuvor beschriebenen Beispielen. Diese Variante ist vor allem nützlich,
wenn die komplette Applikation in einem einzigen jar-Archiv ausgeliefert
wird und nur eine einzige main-Methode
enthält. Sie bietet sich beispielsweise für kleinere Programme,
Beispiel- oder Testapplikationen an (die Demos des JDK sind beispielsweise
in derartigen jar-Dateien untergebracht). Ist die Konfiguration dagegen
komplizierter oder gibt es mehr als eine lauffähige Applikation
in der jar-Datei, sollte der zuvor beschriebenen Variante der Vorzug
gegeben werden.
14.4.2 Einbinden von Ressourcendateien
Wie eingangs erwähnt, benötigt ein Programm neben den Klassendateien
meist weitere Dateien mit zusätzlichen Informationen. Wird auf
diese ausschließlich lesend zugegriffen, wollen wir sie als
Ressourcendateien bezeichnen, also
als Dateien, die dem Programm neben den Klassendateien als zusätzliche
Informationslieferanten zur Laufzeit zur Verfügung stehen. Die
Ressourcendateien könnten zwar als separate Dateien ausgeliefert
und mit den Klassen zur Dateiverarbeitung eingelesen werden (diese
werden ab Kapitel 19
vorgestellt). Das hätte jedoch den Nachteil, dass sich nicht
mehr alle benötigten Dateien in einem jar-Archiv befinden würden
und die Auslieferung dadurch verkompliziert würde.
Glücklicherweise gibt es im JDK die Möglichkeit, auch Ressourcendateien
in jar-Archiven unterzubringen und zur Laufzeit daraus einzulesen.
Mit dem Klassenlader steht das dafür erforderliche Werkzeug allen
Java-Programmen standardmäßig zur Verfügung. Während
der Klassenlader normalerweise von der virtuellen Maschine dazu verwendet
wird, Klassendateien einzulesen, kann er von der Anwendung zum Einlesen
beliebiger Dateien zweckentfremdet werden. Einzige Bedingung ist,
dass die Ressourcendateien in einem Verzeichnis stehen, das vom Klassenlader
erreicht werden kann, das also innerhalb des Klassenpfads liegt.
Dazu kann beispielsweise im Basisverzeichnis der Anwendung ein Unterverzeichnis
resources angelegt werden und die Ressourcendateien
können dort hineinkopiert werden. In unserem Fall würden
wir also ein Unterverzeichnis com\gkrueger\resources
anlegen. Mit Hilfe der Methode getResourceAsStream
der Klasse Class
(siehe Abschnitt 45.2.2)
kann ein InputStream
beschafft werden, mit dem die Datei Byte für Byte eingelesen
werden kann:
Als Parameter wird der vollständige Name der Ressourcendatei
angegeben, allerdings unter Beachtung einiger Besonderheiten. Zunächst
werden die einzelnen Paketnamen nicht wie gewohnt durch Punkte, sondern
durch Schrägstriche »/« voneinander getrennt (auch
unter Windows wird dazu nicht der Backslash verwendet). Nur die Dateierweiterung
wird wie üblich hinter einem Punkt angegeben. Zudem muss als
erstes Zeichen ebenfalls ein Schrägstrich angegeben werden. Soll
also beispielsweise die Datei hello.txt
aus dem Ressourcenverzeichnis geladen werden, so lautet der an getResourceAsStream
zu übergebende Dateiname /com/gkrueger/resources/hello.txt.
Das folgende Listing zeigt eine einfache Methode, in der die angesprochenen
Regeln implementiert werden. Sie beschafft zu einer beliebigen Datei,
die sich in einem vorgegebenen Ressource-Verzeichnis befindet, das
innerhalb des Klassenpfads liegt, einen InputStream,
mit dem die darin enthaltenen Daten eingelesen werden können:
001 private InputStream getResourceStream(String pkgname, String fname)
002 {
003 String resname = "/" + pkgname.replace('.', '/') + "/" + fname;
004 Class clazz = getClass();
005 InputStream is = clazz.getResourceAsStream(resname);
006 return is;
007 }
|
Listing 14.7: Einen InputStream zu einer Ressourcendatei beschaffen
Als Argument wird der Paketname (in Punktnotation) und der Name der
Ressourcendatei angegeben. Den obigen Regeln entsprechend werden beide
in einen Ressourcen-Namen umgewandelt und an getResourceAsStream
übergeben. Diese liefert einen InputStream,
der zum Einlesen der Daten verwendet werden kann. Soll beispielsweise
eine Text-Ressource in einen String
geladen werden, kann dazu folgende Methode verwendet werden:
001 /* TestResource.inc */
002
003 import java.io.*;
004 import java.awt.*;
005
006 //...
007
008 public String loadTextResource(String pkgname, String fname)
009 throws IOException
010 {
011 String ret = null;
012 InputStream is = getResourceStream(pkgname, fname);
013 if (is != null) {
014 StringBuffer sb = new StringBuffer();
015 while (true) {
016 int c = is.read();
017 if (c == -1) {
018 break;
019 }
020 sb.append((char)c);
021 }
022 is.close();
023 ret = sb.toString();
024 }
025 return ret;
026 }
027
028 //...
|
TestResource.inc |
Listing 14.8: Laden einer Text-Ressource
Auch das Laden von Image-Ressourcen
(Programm-Icons, Abbildungen etc.) kann auf ähnliche Weise realisiert
werden:
001 /* ImageResource.inc */
002
003 import java.io.*;
004 import java.awt.*;
005
006 //...
007
008 public Image loadImageResource(String pkgname, String fname)
009 throws IOException
010 {
011 Image ret = null;
012 InputStream is = getResourceStream(pkgname, fname);
013 if (is != null) {
014 byte[] buffer = new byte[0];
015 byte[] tmpbuf = new byte[1024];
016 while (true) {
017 int len = is.read(tmpbuf);
018 if (len <= 0) {
019 break;
020 }
021 byte[] newbuf = new byte[buffer.length + len];
022 System.arraycopy(buffer, 0, newbuf, 0, buffer.length);
023 System.arraycopy(tmpbuf, 0, newbuf, buffer.length, len);
024 buffer = newbuf;
025 }
026 //create image
027 ret = Toolkit.getDefaultToolkit().createImage(buffer);
028 is.close();
029 }
030 return ret;
031 }
032
033 //...
|
ImageResource.inc |
Listing 14.9: Laden einer Image-Ressource
Voraussetzung ist natürlich, dass das Format der in den Puffer
buffer eingelesenen Datei von
der Methode createImage
verstanden wird. Beispiele für gültige Formate sind GIF
oder JPEG.
Der große Vorteil bei dieser Vorgehensweise ist, dass sie sowohl
mit separaten Klassendateien funktioniert, als auch, wenn die komplette
Applikation inklusive der Ressourcendateien innerhalb einer einzigen
jar-Datei ausgeliefert wird. Für die Anwendung selbst ist es
vollkommen gleichgültig, aus welcher Quelle die Dateien stammen.
