4 Unterschiede zwischen Java- Applikationen und -Applets

Nachdem nun die wichtigsten Voraussetzungen (Einiges an Grundlagentheorie und diverse Werkzeuge) besprochen wurden, wollen wir konkret zu einem ersten Einstieg in die Java-Programmierung kommen. Sie sollen ja nicht die Lust verlieren, weil wir einfach nicht zu Java kommen.

Ein oft gemachter Fehler bei Java-Laien besteht darin, Java-Applikationen und Java-Applets gleichzusetzen. Um diesem Missverständnis vorzubeugen, soll an dieser Stelle der Unterschied zwischen Java-Applikationen und -Applets besprochen werden. Auf viele Details in der Programmierung wird zwar hier nicht eingegangen, jedoch einige Grundlagen sollen doch diskutiert werden.

Ein Hauptgrund für die heutige Beliebtheit von Java beruht sicher auf den Java-Applets, die erst richtig Leben in das WWW gebracht haben. Solche Java-Applets können nur innerhalb eines Webbrowsers oder des Appletviewers ausgeführt werden. Ein solcher Container bildet quasi ein zweites Betriebssystem für Applets. Da beide Programme aber HTML-Seiten anzeigen, muss ein Applet über eine solche HTML-Seite referenziert werden. Eine entsprechende Referenz innerhalb einer HTML-Seite mit einem speziellen Tag - dem <APPLET>-Tag - erledigt die Einbettung in den Browser.

Seit der HTML-Version 4.0 kann die Einbettung von Java-Applets in Webseiten ebenso mittels des allgemeineren <OBJECT>-Tags erfolgen. Das ursprünglich nur für ActiveX- Controls verwendete <OBJECT>-Tag dient seit HTML 4 zum Einbinden von allgemeinen Objekten. Darunter fallen u.a. Bilder, Video- und Tondateien und eben auch spezialisierte Applikationen wie Java-Applets. Damit werden im Prinzip einige bisherige Tags - so auch das <APPLET>-Tag - überflüssig. Statt vielen verschiedenen Tags ist nur noch das <OBJECT>-Tag notwendig. Die Browser unterstützen die bisherigen Tags jedoch nach wie vor. Außerdem gibt es nachfolgend noch besprochene Gründe, warum die Verwendung von <APPLET> sinnvoller sein kann.

Abbildung 4.1:  Ein Applet innerhalb eines Browsers

Da Java-Applets innerhalb eines Browsers laufen, haben sie direkten Zugang zu den meisten Fähigkeiten desBrowsers. Dazu zählen u.a. Zugriffe auf Grafiken und Elemente der Benutzeroberfläche, aber auch Netzwerkfähigkeiten.

Allerdings teilen sie auch die Einschränkungen des Browsers - oder genauer: Sie werden durch den Browser beschränkt. Das beinhaltet beispielsweise die fehlende Möglichkeit, das Dateisystem des Rechners zu lesen und dort Schreibvorgänge durchzuführen. Es sei denn, der Anwender erlaubt es, indem die Sicherheitseinstellungen des Containers entsprechend gelockert werden. Weiter können Applets normalerweise nur zu dem Host Verbindung aufnehmen, von dem sie geladen wurden. Auch hierzu sind in den Einstellungen des Appletviewers bzw. des Browsers entsprechende Veränderungen möglich, die dann eine noch geringere, aber auch weitergehende Kommunikation erlauben.

Zwei weitere Einschränkungen von Applets gehen über diese Eigenschaften hinaus. Zum einen können Applets keine auf dem Client-System vorhandenen Programme starten, zum anderen können Sie keine nativen Programme und Bibliotheken der lokalen Plattform laden. Bugs in älteren Java-Versionen, die in diese Richtung Manipulationsmöglichkeiten eröffneten, werden beim Java-Sicherheitskonzept angesprochen. Darüber hinaus müssen Java-Applets noch diverse weitere Sicherheitsregularien einhalten, auf die ebenfalls noch näher eingegangen wird. Applets ist insbesondere die Unterbrechung der Ausführung des Java-Interpreters nicht erlaubt. Sie können also die Methode System.exit() nicht aufrufen.

Dies alles mag erst einmal als Einschränkung und Argumente gegen Applets empfunden werden, aber genau das Gegenteil ist der Fall. Immerhin soll ein Anwender ja via Browser ein Programm auf seinen Rechner lassen, dessen Funktionalität er nicht kennen kann. Wenn man als Anwender sicher sein kann, dass zumindest die verwendete Technologie keinen Schaden anrichten kann, wird das die Akzeptanz erheblich erhöhen. Applets erlauben nur solche Aktionen, die einen Anwender so gut wie nicht schädigen können. Zumindest muss man sich mit Java-Applets erheblich anstrengen, wenn man einen Anwender ärgern will. Mit anderen Technologien geht das viel leichter.

Java-Applikationen sind im Gegensatz zu Applets vollständig in Java programmierte und eigenständig lauffähige Programme. Sie benötigen im Kontrast zu den Applets keine Container mehr (beispielsweise einen Browser oder den Appletviewer). Sie laufen direkt in der virtuellen Maschine und haben dementsprechend weitergehende Möglichkeiten auf dem lokalen System. Das ist auch sinnvoll, denn sonst könnten keine konkurrenzfähigen Applikationen in Java entwickelt werden. Anders gesagt - eine Java-Applikation kann all das leisten, was sie auch können würde, wenn sie in einer anderen Programmiersprache erstellt worden wäre.

Abbildung 4.2:  Das Applet als eigenständige Applikation

4.1 Die technischen Unterschiede

Eine eigenständig lauffähige Java-Applikation benötigt immer eine zentrale Methode, deren Abarbeitung dem gesamten Programmlauf entspricht: die main()-Methode. Genau betrachtet besteht die Ausführung einer Java-Applikation nur aus dem Start, der Durchführung und dem Ende der main()-Methode. Sämtliche Aktionen der Java-Applikation werden von da aus gesteuert und aufgerufen. Die genaue Syntax sieht so aus:

public static void main (String args[])

Beim Java-Applet ist es etwas anders. Es gibt als wesentlichen Unterschied keine main()-Methode.

Ein Applet benötigt zwar keine Methode namens main(), das bedeutet aber nicht, dass dort eine solche Methode verboten ist. Insbesondere solche Applets, die alternativ als eigenständige Applikation lauffähig sein sollen, besitzen eine solche main()-Methode. Beim Start als Applet wird sie nur nicht verwendet.

Das Leben eines Applets vollzieht sich in vier Schritten:

Wenn Sie sich das Menü des Appletviewers ansehen, werden Sie dort die Befehle Stop und Start wiederfinden.

Abbildung 4.3:  Im Menü des Appeltviewers sind die Start- und Stop-Anweisungen wiederzufinden.

Es ist an der Zeit für Java-Praxis.

4.2 Eine erste Beispielanwendung und ein erstes Applet

Wir wollen an dieser Stelle eine erste Beispielanwendung und ein erstes Applet erstellen. Dabei ignorieren wir bewusst die Situation, dass bisher noch überhaupt kein systematischer Aufbau der Syntax, der Java-Konzepte oder der Befehle erfolgt ist. Auch von grundlegenden Vorgehensweisen bei der Programmierung in Java war noch keine Rede. Um jedoch nach so viel Theorie ein Erfolgserlebnis in der Praxis zu haben, ist es an dieser Stelle sicher sinnvoll, konkrete Beispiele dazwischenzufügen. Natürlich werden die beiden jetzt folgenden Beispiele sehr einfach sein.

4.2.1 Eine erste Applikation

Das klassische »Hello world«-Programm wollen wir als Basis für unser erstes Programm nutzen. Damit bewegen wir uns in bester Tradition fast aller Bücher über Programmiersprachen seit mystischer Basic-Zeit, die dieses Beispiel als Einstieg verwendet haben.

Die einzelnen Schritte sollten bei einem ersten Kontakt am besten sklavisch nachvollzogen werden (d.h. mit strenger Beachtung von Namen und Groß- und Kleinschreibung). Erklärungen der dahinter liegenden Prozesse folgen an späterer Stelle. Hier gilt nur: Hauptsache, »it works«.

Da Java innovativ ist, wollen wir in demselben Maße eine innovative Änderung gegenüber dem klassischen »Hello world«-Programm vornehmen.

Starten Sie bitte einen beliebigen ASCII-Editor und geben nach folgenden Quelltext ein.
class HelloJava {
    public static void main (String args[]) {
        System.out.println("Hello Java!");
    }  }

Haben Sie die extrem innovative Änderung bemerkt ;-)?

So, jetzt haben Sie Ihr erstes Java-Programm geschrieben, aber wie geht es weiter? Speichern ist der nächste notwendige Schritt. Es mag trivial erscheinen, aber die Betonung liegt wirklich auf »notwendig«, was bei integrierten Entwicklungsumgebungen nicht der Fall ist. Dort würde es heißen: »Speichern ist der nächste sinnvolle Schritt«. Da wir unter dem JDK zur Übersetzung des ASCII-Textes jedoch im Folgeschritt ein Programm aufrufen müssen, das eine Datei auf einem (beschreibbaren) Datenträger erwartet, muss unbedingt gespeichert werden, bevor wir mit dem Java-Source etwas anfangen können.

Wenn wir davon ausgehen, dass Sie Ihre Pfadangaben entsprechend den Empfehlungen bei der Besprechung des JDK gesetzt haben, können Sie Ihr erstes Programm an einem beliebigen Platz (z.B. im extra erstellten Verzeichnis ErstesProgramm) speichern.

Speichern Sie jetzt Ihr Programm in einem Verzeichnis Ihrer Wahl.

Speichern Sie den Quelltext unter dem Namen ErstesJavaProgramm ab.

War das korrekt so? Eigentlich sollten Sie einen Fehler bereits mit Ihren jetzigen Kenntnissen entdecken. Welche Erweiterung hat jeder Java-Source (nicht der Bytecode)? Wenn Sie sich eine Fehlermeldung bei dem nachfolgenden Aufruf des Compilers sparen wollen, dann speichern Sie das Programm besser mit der Erweiterung .java (Groß- und Kleinschreibung bitte unbedingt beachten), also unter dem Namen ErstesJavaProgramm.java ab.

Im nächsten Schritt versuchen wir, den gespeicherten Java-Source zu kompilieren.

Öffnen Sie ein Befehlzeilenfenster und wechseln Sie dort in das Verzeichnis, wo der Java- Source abgelegt ist. Dort rufen wir den Java-Compiler auf.

Geben Sie Folgendes ein:

javac ErstesJavaProgramm

Was passiert? Etwa eine Fehlermeldung? Trotz richtig eingestellter Java-Umgebung? Natürlich, wir haben die Erweiterung vergessen. Also zweiter Versuch mit Erweiterung:

javac ErstesJavaProgramm.java

Nun müsste alles glatt gegangen sein. Sollten Sie immer noch eine Fehlermeldung erhalten haben, so warten Sie noch einmal kurz ab. Ansonsten ist es Zeit, das in Bytecode übersetzte Programm auszuführen.

Wie geht das? Sie müssen den Java-Interpreter aufrufen und die auszuführende Klasse als Parameter übergeben. Die Klasse bekommt nach der Definition von Java den gleichen Namen wie der Source und die Erweiterung .class.

Geben Sie auf Befehlszeilenebene den nachfolgenden Aufruf ein.
java ErstesJavaProgramm.class

Was passiert? Etwa schon wieder eine Fehlermeldung? Natürlich, wir haben diesmal die Erweiterung eingegeben und beim Interpreter darf sie nicht eingegeben werden. Also: Zweiter Versuch ohne Erweiterung.

Geben Sie auf Befehlszeilenebene den nachfolgenden Aufruf ein.
java ErstesJavaProgramm

So, jetzt müsste alles geklappt haben. Oder etwa nicht? Noch eine Fehlermeldung, dass die Klasse nicht gefunden wurde?

Geben Sie auf Befehlszeilenebene den nachfolgenden Aufruf ein.

java HelloJava

Nanu, jetzt steht Hello Java in der untersten Ausgabezeile oder nicht?! Herzlichen Glückwunsch, Sie haben Ihr erstes Java-Programm erstellt und zum Laufen gebracht. Lassen Sie sich mal den Inhalt Ihres Testverzeichnisses anzeigen (etwa mit dem Befehl DIR direkt in der DOS-Box, dem Arbeitsplatz oder einem anderen Dateimanagement-Programm), dann erkennen Sie wahrscheinlich den Grund, warum es jetzt funktioniert und nicht bei java ErstesJavaProgramm. Es gibt keine Klasse mit dem Namen ErstesJavaProgramm.class, dafür aber eine Klasse mit dem Namen HelloJava.class. Der Compiler verwendet für die Generierung des Klassennamens nicht den Namen der Java-Sourcedatei, sondern den Namen, den Sie als Bezeichner Ihrer Klasse verwendet haben.

Wie schon an verschiedenen Stelle erwähnt: Unter Java werden lange Dateinamen verwendet. In einer DOS-Box werden bei Verwendung des DIR-Befehls unter Umständen nur die verkürzten Namen dargestellt, zumindest in der ersten Ausgabespalte. Dies ist eine gefährliche Fehlerquelle, wenn Sie da nicht aufpassen.

Ich habe Sie mit der Wahl eines abweichenden Namens bewusst aufs Glatteis geführt, damit Ihnen dieser Zusammenhang klar wird. Wenn Sie wollen, können Sie Ihren Java-Source noch mal unter dem Namen Ihrer Klasse (also HelloJava.java) abspeichern und die Schritte noch einmal nachvollziehen. Prinzipiell sollten Java-Source-Dateien unter dem Namen Ihrer public-Klasse (einer gesondert markierten Klasse - Genaueres folgt später) gespeichert werden, um überhaupt keine Missverständnisse aufkommen zu lassen.

Zu einer kurzen Erläuterung des Sources soll an dieser Stelle nur Folgendes gesagt werden:

1. Das gesamte Programm befindet sich innerhalb der Klassendefinition.
2. Die bei einer eigenständigen Applikation unbedingt notwendige main()-Methode enthält nur einen Ausgabenaufruf auf das Standardausgabegerät.

4.2.2 Übergabe von Aufrufargumenten an ein Java-Programm

Natürlich kann man an ein Programm beim Aufruf Parameter übergeben, die das Programm dann verwenden kann. Damit kann man das im Prinzip abgeschlossene Programm beeinflussen. Dies dient etwa zur Ablaufsteuerung, zur Einstellung von Optionen, zur Weitergabe von zu verarbeitenden Werten usw.

Argumente an ein Programm werden auf Befehlszeilenebene einfach an den Programmaufruf - mit Leerzeichen abgetrennt - angehängt.

Verändern wir doch unser erstes Programm ein wenig, sodass es Argumente auswerten kann.

Geben Sie den nachfolgenden Quelltext ein.

class HelloJava2 {
    public static void main (String args[]) {
        System.out.println(args[0]);
}  }

Speichern Sie das Programm unter HelloJava2.java.
Kompilieren Sie es neu. Geben Sie auf Befehlszeilenebene den nachfolgenden Aufruf ein.
javac HelloJava2.java

Geben Sie auf Befehlszeilenebene den nachfolgenden Aufruf zum Start des Programms ein.
java HelloJava2 "HelloJava"

Die Ausgabe müsste identisch sein.

Beachten Sie, dass das Programm nicht gegen das Fehlen von Übergabewerten geschützt ist.

Der in Hochkommata eingeschlossene Übergabewert1 steht über das Zeichenketten-Array args (oder den sonst in der main()-Methode angegebenen Namen) zur Verfügung. Innerhalb der main()-Methode können Übergabeparameter beliebig behandelt werden.

Der Index eines Arrays in Java beginnt mit 0.

Wir werden später noch einmal auf die Übergabe von Werten an ein Java-Programm zurückkommen. Insbesondere werden wir darauf eingehen, was man mit den übergebenen Werten alles machen kann und worauf Sie zu achten haben, wenn Sie nicht nur übergebene Zeichen als Text weiter verwenden wollen.

Da die Argumentenliste eines Programms immer ein Zeichenketten-Array ist, werden alle Übergabeparameter an ein Java-Programms als Zeichenketten übergeben.

Kommen wir nun zur Erstellung eines ersten Applets.

4.2.3 Ein erstes Applet

Möglicherweise wider Ihre Erwartung ist die Erstellung eines einfachen Applets - mit ähnlicher Funktionalität wie das gerade behandelte Programm - komplizierter als die Erstellung der eigenständigen Applikation. Allerdings könnte auf Grund der technischen Unterschiede zwischen Applets und Applikationen schon eine Ahnung aufgekommen sein, dass Applet-Code nicht ganz so einfach sein kann. Eine eigenständig lauffähige Java-Applikation benötigt immer nur eine main()-Methode (siehe Beispiel), während das Java-Applet zwar keine main()-Methode, dafür gleichwohl beivoller Funktionsfähigkeit mindestens vier andere Methoden benötigt - die init()-Methode, die start()-Methode, die stop()-Methode und die destroy()-Methode.

Allein daraus dürfte klar werden, dass da eine Menge mehr Source notwendig ist, wenn Sie ein vollständig funktionsfähiges Applet bauen wollen. Lassen Sie uns dennoch ein einfaches Applet erstellen, das genauso wie die eigenständige Applikation aus dem vorigen Beispiel Hello Java ausgibt. Der Quelltext wird trotz der einleitenden Warnung kaum größer als bei der eigenständigen Applikation sein. Dies liegt daran, dass wir diese Methoden nicht direkt notieren müssen. Implizit stecken diese Methoden allerdings dennoch in dem nachfolgenden Beispiel. Es erbt sie über die Syntax extends java.applet.Applet von der Mutter aller Applets (was auch immer das jetzt bedeutet).

Dafür müssen wir aber etwas anderes tun. Wir können nicht einfach wie bei einer eigenständigen Applikation einen Ausgabenaufruf auf das Standardausgabegerät nutzen. Ein Applet befindet sich innerhalb eines Containers und muss sich kooperativ zu ihm verhalten. Es muss die Ausgabemöglichkeiten nutzen, die mit dem Container kooperieren, also meistens Fenster im Rahmen einer grafischen Oberfläche. Wir werden das Applet als eine Instanz einer Klasse erstellen, die uns diese Funktionen zur Verfügung stellt. Innerhalb des Fensters wird dann auch nicht mehr geschrieben, sondern eher gemalt, was eine andere Methode zur Ausgabe erzwingt. Außerdem benötigen wir eine HTML-Datei, mit der wir das Applet dann in unseren Container implementieren.

Gehen wir das erste Applet-Projekt systematisch an.

Als Erstes erstellen wir ein eigenes Verzeichnis für das Projekt (Vorschlag ErstesApplet), in dem sich anschließend die HTML-, die Java- und die Klassendatei befinden sollen.

Starten Sie einen ASCII-Editor und geben Sie nachfolgenden Quelltext ein.

import java.awt.Graphics; 
public class HelloJavaApplet extends java.applet.Applet {
    public void paint(Graphics g)    {
  g.drawString("Hello Java!", 5, 25);
    }  }

Dies ist Ihr erstes Java-Applet. Und wie geht es weiter? Wie bei der Applikation mit Speichern als dem nächsten notwendigen Schritt.

Speichern Sie Ihren Quelltext in einem Verzeichnis Ihrer Wahl.

Speichern Sie den Quelltext unter dem Namen

HelloJavaApplet.java

ab (wir müssen alle didaktisch bewusst gemachten Fehler von der Applikation ja nicht wiederholen, oder?!).

Im nächsten Schritt werden wir den gespeicherten Java-Source wieder kompilieren.

Öffnen Sie wieder ein Befehlzeilenfenster und wechseln Sie dort in das Verzeichnis, wo der Java-Source abgelegt ist.

Rufen Sie den Java-Compiler auf.

Geben Sie Folgendes ein:

javac HelloJavaApplet.java

Falls Sie keine Tippfehler gemacht haben, sollte die Übersetzung gelungen sein. Der Compiler gibt bei erfolgreicher Übersetzung keine Rückmeldung (nur im Fehlerfall), deshalb sollten Sie zur Sicherheit den Inhalt des Verzeichnisses überprüfen. Es müssen zwei Dateien vorhanden sein (HelloJavaApplet.java und HelloJavaApplet.class).

Der Appletviewer (oder ein Java-fähiger Browser) benötigt zum Aufruf des Applets eine HTML-Datei als Gerüst.

Wir erstellen nun in einem beliebigen ASCII-Editor unsere HTML-Datei zum Aufruf des Applets.

Auch hier verwenden wir nur eine extrem rudimentäre Struktur. Geben Sie Folgendes ein:

<HTML>
<BODY>
<APPLET CODE="HelloJavaApplet.class" 
  WIDTH=150 HEIGHT=25></APPLET>
</BODY>
</HTML>

Speichern Sie nun Ihre HTML-Datei in dem gleichen Verzeichnis ab, wo sich die .class-Datei befindet.

Bei Ihrer Wahl des Namens für Ihre HTML-Datei sind Sie hier vollkommen frei. Allerdings gilt immer: je sprechender, desto besser. Vorschlag: AppletAufruf.html.

Schauen Sie sich nun das Applet an.

Dazu können wir jeden beliebigen Java-fähigen Browser verwenden. Laden Sie beispielsweise die HTML-Datei per Doppelklick im Windows-Explorer in Ihren Standardbrowser oder öffnen Sie sie als lokale Datei in dem Datei-Menü des Browsers.

Sie sollten auf jeden Fall etwas Ähnliches sehen wie im nachfolgenden Screenshot.

Abbildung 4.4:  Das erste Applet im Internet Explorer

Sie können ebenfalls den im JDK integrierten Appletviewer zum Ansehen verwenden.

Schauen Sie sich das Applet im Appletviewer an.

Geben Sie bitte zum Aufruf des Appletviewers Folgendes ein:

appletviewer HelloJavaApplet

Was erhalten Sie? Natürlich wieder eine Fehlermeldung. Vorsicht Glatteis. Sie müssen die HTML-Datei aufrufen.

appletviewer AppletAufruf.html

Das Resultat müsste dann so ähnlich wie im nachfolgenden Screenshot aussehen.

Abbildung 4.5:  Das erste Applet im Appletviewer

Natürlich können auch Übergabeparameter an Applets weitergegeben werden. Dies ist jedoch nicht so einfach wie bei eigenständigen Java-Applikationen. Wir werden diesen Vorgang deshalb in einem späteren Kapitel - wenn uns bereits mehr Java-Kenntnisse zur Verfügung stehen - besprechen. Dort finden Sie dann auch noch weitere Details zu Applets - vor allem der Einbindung in HTML-Seiten.

4.3 Zusammenfassung

Java-Applikationen und Java-Applets sind zwar eng verwandt, nicht aber gleichzusetzen. Insbesondere muss für Applets erst einmal etwas mehr Aufwand betrieben werden als für eigenständige Applikationen. Dies relativiert sich jedoch, wenn die Anwendungen komplexer werden. Applets können zwar nur innerhalb eines Webbrowsers oder des Appletviewers ausgeführt werden, ihnen steht aber dann die vollständige Funktionalität dieses Containers zur Verfügung. Andererseits werden sie von diesem Container in ihrer Funktionalität beschränkt.

Die Einbettung in den Browser-Container erfolgt über eine entsprechende Referenz innerhalb einer HTML-Seite mit einem speziellen Tag - dem <APPLET>-Tag. Alternativ kann beispielsweise das neuere <OBJECT>-Tag verwendet werden, das aber alte Browser nicht verstehen und gegen dessen Verwendung auch einige weitere - noch später besprochene - Gründe sprechen. Allerdings gibt es natürlich auch Argumente für dessen Verwendung, die wir ebenso anführen werden.

Java-Applikationen sind vollständig in Java programmierte und eigenständig lauffähige Programme, die im Gegensatz zu den Applets keine Container mehr benötigen (von der zwingend notwendigen Existenz der so genannten virtuellen Java-Maschine abgesehen).

Die technischen Unterschiede konzentieren sich im Wesentlichen in der Tatsache, dass eine eigenständige Applikation immer eine main()-Methode benötigt, während ein Applet diese nicht verwendet.

1

Das ist notwendig, da sonst das Leerzeichen vom Interpreter als Trennung von zwei Übergabewerten verstanden würde.


© Copyright Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH
Elektronische Fassung des Titels: Java 2 Kompendium, ISBN: 3-8272-6039-6 Kapitel: 4 Unterschiede zwischen Java- Applikationen und -Applets