From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../hjp5/html/k100086.html | 305 +++++++++++++++++++++ 1 file changed, 305 insertions(+) create mode 100644 Master/Reference Architectures and Patterns/hjp5/html/k100086.html (limited to 'Master/Reference Architectures and Patterns/hjp5/html/k100086.html') diff --git a/Master/Reference Architectures and Patterns/hjp5/html/k100086.html b/Master/Reference Architectures and Patterns/hjp5/html/k100086.html new file mode 100644 index 0000000..7df5cd3 --- /dev/null +++ b/Master/Reference Architectures and Patterns/hjp5/html/k100086.html @@ -0,0 +1,305 @@ + + + +Handbuch der Java-Programmierung, 5. Auflage + + + + + + + + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage +
 <<  +  <   +  >   + >>  + API  +Kapitel 13 - Strukturierung von Java-Programmen +
+
+ + + + +

13.3 Der Entwicklungszyklus

+
+ +
+ + + + +

13.3.1 Schematische Darstellung

+ +

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

+ +

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

+ + +

+ +

+Abbildung 13.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 13.2 +zeigt dies beispielhaft. +

+ + +

+ +

+Abbildung 13.2: Plattformübergreifende Entwicklung in Java

+ + + + +

13.3.2 Projektverwaltung

+ + + + +

Getrenntes Kompilieren

+ +

+Wie die Abbildungen deutlich machen, spielen die .class-Files + für den Entwicklungsprozess +und die Portierbarkeit von Java-Programmen eine entscheidende Rolle. +Jede .class-Datei 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. +

+ + + + + + + + + +
+ +

+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 eindeutige 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.

 + + + + +
 Hinweis 
+
+ +

+Wie bereits angedeutet, dürfen tatsächlich auch zwei oder +mehr Klassen in einer Quelldatei enthalten sein. Voraussetzung dafür +ist allerdings, dass 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, gibt es einen Compiler-Fehler. +

+ + + + + + + + + + + +
+ +

+Wichtig ist in dem Zusammenhang auch, dass der Name der public-Klasse +und der Name der Quelldatei identisch sein müssen. Dabei muss +die Groß- und Kleinschreibung eingehalten werden, und auch bei +Klassennamen, die länger als 8 Zeichen sind, muss 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, +kaum sinnvoll möglich und bisher auch nur ansatzweise gelungen.

 + + + + +
 Warnung 
+
+ +

+Interessanterweise bietet Java volle Typsicherheit +auch über die Grenzen von Quelldateien hinweg, ohne dass 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. + + + + +

Java und make

+ +

+Genau aus diesem Grund ist aber auch die Verwendung des make-Tools +zur Verwaltung der Dateiabhängigkeiten in Java-Projekten schwierig. +Anstelle der klar definierten Abhängigkeit einer Quelldatei von +einigen Headerdateien besitzt eine Java-Quelle meist eine Vielzahl +von (teilweise impliziten oder indirekten) Abhängigkeiten zu +anderen Java-Quellen. Diese korrekt zu pflegen ist nicht einfach, +und ein makefile +kann leicht unvollständige Abhängigkeitsregeln enthalten. +Die daraus entstehenden Inkonsistenzen können zu schwer zu lokalisierenden +Laufzeitfehlern führen. + +

+Ein anderes Problem bei der Verwendung von make +ist die Vielzahl der separaten Compiler-Aufrufe. Da der Java-Compiler +des JDK selbst in Java geschrieben wurde, verursacht jeder Aufruf +einen erheblichen Overhead durch das erforderliche Starten der virtuellen +Maschine, der sich bei umfangreichen Projekten in unzumutbaren Wartezeiten +niederschlägt. +

+ + + + + + + + + + + +
+ +

+Aus diesen Gründen ist es bei kleineren und mittleren Projekten +oftmals sinnvoll, auf den Einsatz von make +zu verzichten und die Programme bei Bedarf durch Aufruf von javac +*.java komplett neu zu kompilieren. Der Aufruf-Overhead +entsteht in diesem Fall nur einmal, und der Compiler braucht nicht +wesentlich länger, als wenn lediglich eine einzige Quelle übersetzt +würde. + +

+Eine Alternative zu make +ist das Open-Source-Projekt ant, +ein komplett in Java geschriebenes make-Tool +mit umfangreichen Scripting-Möglichkeiten. ant +kann am ehesten als Kombination aus make +und Kommando-Shell angesehen werden. Basierend auf XML als Steuerungssprache +bietet es eine Vielzahl von eingebauten Kommandos, die beim Übersetzen +von Java-Programm und während des gesamten Build-Prozesses nützlich +sind. Eigene Erweiterungen können in Java geschrieben und nahtlos +integriert werden. ant +wird als Jakarta-Projekt entwickelt, +und seine Homepage ist http://ant.apache.org/.

 + + + + +
 Tipp 
+
+

+ + + +
 Titel  + Inhalt  + Suchen  + Index  + DOC  +Handbuch der Java-Programmierung, 5. Auflage, Addison +Wesley, Version 5.0.1 +
 <<  +  <   +  >   + >>  + API  +© 1998, 2007 Guido Krüger & Thomas +Stark, http://www.javabuch.de +
+ + + -- cgit v1.2.3