Guido Krüger - JAVA 1.1 lernen - Kapitel 8

• Kapitel 8 - Bestandteile eines Programms
  • Der Entwicklungszyklus
    • Schematische Darstellung
    • Getrenntes Kompilieren

Der Entwicklungszyklus

Schematische Darstellung

Der Turn-Around-Zyklus beim Entwickeln von Java-Programmen unterscheidet sich in mehrfacher Hinsicht von dem in traditionellen kompilierten Programmiersprachen.

• Der Compiler erzeugt keine direkt ausführbaren Programme, sondern .class-Files, die von einem Java-Interpreter ausgeführt werden. Mittlerweile arbeiten bereits mehrere Betriebssystem-Hersteller daran, .class-Files direkt ausführbar zu machen, und es gibt schon Prozessoren, die den Maschinencode in .class-Files ohne zwischengeschalteten Interpreter verstehen.
• Es gibt es keinen expliziten Link-Lauf, denn die verschiedenen .class-Files werden zur Ausführungszeit gebunden.
• Die .class-Files eines einzigen Projekts können auf unterschiedlichen Plattformen mit unterschiedlichen Compilern erzeugt worden sein.
• Die .class-Files lassen sich auf allen Plattformen ausführen, die einen Java-Interpreter besitzen; unabhängig davon, wo sie ursprünglich entwickelt wurden.

Abbildung 8.1 zeigt den schematischen Ablauf bei der Entwicklung eines Java-Programms, das aus den Klassen A, B und C besteht.

Abbildung 8.1: Der Entwicklungszyklus in Java

Da der Java-Bytecode plattformunabhängig ist, hätten die Klassen A, B und C aber auch ebensogut von verschiedenen Entwicklern auf drei unterschiedlichen Plattformen entwickelt werden können, um später auf einer vierten Plattform ausgeführt zu werden. Abbildung 8.2 zeigt dies beispielhaft.

Abbildung 8.2: Plattformübergreifende Entwicklung in Java

Getrenntes Kompilieren

Wie die Abbildungen deutlich machen, spielen die .class-Files für den Entwicklungsprozeß und die Portierbarkeit von Java-Programmen eine entscheidende Rolle. Jedes .class-File enthält den Bytecode für eine übersetzte Klasse. Zusätzlich sind in ihr Informationen enthalten, um dynamisches Linken und Late-Bindung zu unterstützen und gegebenenfalls Symbole, Zeilennummern und andere Informationen für den Debugger zur Verfügung zu stellen.

Hinweis

Eine der Grundregeln bei der Entwicklung von Java-Programmen ist es, genau eine Klassendefinition je Quelldatei aufzunehmen. Anders als etwa in C++ ist es in Java grundsätzlich nicht möglich, die Quellen einer einzigen Klasse auf mehrere Dateien zu verteilen (und auf diese Weise weniger als eine Klasse in einer Quelldatei zu speichern). Obwohl es - wie wir gleich sehen werden - möglich ist, mehr als eine Klasse in einer Quelldatei abzulegen, sollte dies in der Regel nicht getan werden. Wenn diese Regeln eingehalten werden, ergibt sich eine eineindeutige Abbildung zwischen Klassen und Quelldateien, die bei der sauberen Strukturierung eines Projektes hilft. Durch die Verwendung von Paketen kann eine Verteilung der Quelltexte auf verschiedene Verzeichnisse und Unterverzeichnisse erreicht werden.

Wie bereits angedeutet, dürfen tatsächlich auch zwei oder mehr Klassen in einer Quelldatei enthalten sein. Voraussetzung dafür ist allerdings, daß höchstens eine von ihnen als public deklariert wurde. Eine solche Vorgehensweise kann beispielsweise bei sehr kleinen Projekten, die nur aus ganz wenigen Klassen bestehen, sinnvoll sein, um alle Klassen in eine einzige Datei zu bekommen. Sie kann auch angewendet werden, wenn kleine Hilfsklassen benötigt werden, die nur für eine einzige andere Klasse von Bedeutung sind. Der Compiler erzeugt in jedem Fall eine separate .class-Datei für jede Klasse, die in einer Quelldatei enthalten ist. Wurde in einer Quelldatei mehr als eine Klasse public deklariert, so gibt es einen Compiler-Fehler.

Warnung

Wichtig ist in dem Zusammenhang auch, daß der Name der public-Klasse und der Name der Quelldatei identisch sein müssen. Dabei muß die Groß- und Kleinschreibung eingehalten werden und auch bei Klassennamen, die länger als 8 Zeichen sind, muß der Dateiname so lang wie der Klassenname sein. Klassen- und Dateiname unterscheiden sich also nur durch die Extension .java. So befindet sich beispielsweise die Klasse Integer in einer Datei mit dem namen Integer.java und die Klasse InterruptedException in einer Datei mit dem Namen InterruptedException.java. Da die Extension einer Java-Quelldatei in jedem Fall .java (und damit vierstellig) ist, ist eine vernünftige Portierung von Java auf Plattformen, die nur 8+3-Dateinamen unterstützen, von vornherein kaum sinnvoll möglich.

Interessanterweise bietet Java volle Typsicherheit auch über die Grenzen von Quelldateien hinweg, ohne daß dazu Header-Dateien oder andere Interface-Beschreibungen nötig wären. Der Compiler verwendet während der Übersetzung einer Java-Klasse die .class-Dateien aller eingebundenen Klassen und entnimmt diesen die Signatur der aufgerufenen Methoden. Die Notwendigkeit zur Bereitstellung von separaten Header-Dateien (wie beispielsweise in C++) und das fehlerträchtige Management der Abhängigkeiten zwischen ihnen und ihren Quelltexten entfällt daher.