|
5.1 Aufbau und Konzepte
In diesem Kapitel soll ein Überblick über die Konzepte von Java gegeben werden. In der Knappheit, die diesem Dokument auferlegt wurde, können natürlich nicht alle Aspekte mit der nötigen Tiefe erörtert werden. Es wurde jedoch versucht alle Besonderheiten der Sprachkonzepte Javas zu würdigen.
5.1.1 Kurzeinführung in JAVA
Was ist JAVA?
JAVA ist eine Programmiersprache.
Beim Design von Java wurde versucht die Goodies der bekannten Programmiersprachen zu übernehmen und deren Nachteile die sich im Laufe deren Existenz gezeigt haben auszubügeln. Java ist rein objektorientiert und hat keine strukturellen Überbleibsel, wie das z.B. in C++ der Fall ist. Java sollte alles enthalten, was das Programmieren angenehm macht und dabei mit einer klar überschaubaren und redundanzfreien Syntax auskommen.
Nach SUN (https://java.sun.com/java.sun.com/allabout.html):
Java is a simple, robust, object-oriented, platform-independent multi-threaded, dynamic general-purpose programming environment. It\'s best for creating applets and applications for the Internet, intranets and any other complex, distributed network.
Java entstand aus der deprimierenden Erfahrung Suns, daß die vorhandenen "neuen" Programmiersprachen mit neuen Programmierparadigmen keinesfalls eine revolutionäre Erleichterung in der Softwareentwicklung mit sich brachten. Java soll nun endlich die Vorzüge neuer Entwicklungsmethoden auf die Ebene der Programmiersprache bringen und dem Programmierer das "Leben" erleichtern.
Was kann JAVA?
Java kann nicht mehr und nicht weniger als andere Programmiersprachen auch. Durch die Konzeption eignet sich Java jedoch für eine Fülle von Anwendungen die Plattformunabhängigkeit macht Java z.B. zur idealen Programmiersprache für verteilte Anwendungen, insbesondere im WWW. Dabei bleibt der Anspruch auf Portabilität nicht im leeren Raum (man erinnert sich noch vage an die Aussage das C eine portable Programmiersprache ist) , der praktische Einsatz verschiedener Java Applikationen und insbesondere der Applets zeigt, daß Java durch seine Konzepte wirklich auf den unterschiedlichsten Plattformen lauffähig ist.
Verschiedene große Betriebsystem Hersteller wollen Java als Bestandteil in ihre Betriebsysteme integrieren. Dazu gehören z.B. Micro$oft, IBM und Apple.
Was kann JAVA nicht?
Kaffee kochen.
5.1.2 Gegenüberstellung Java - herkömmliche Programmiersprachen
Um JAVA gegenüber den bekannten Programmiersprachen abgrenzen zu können werden wir zunächst Unterschiede und Gemeinsamkeiten heraus arbeiten und dann auf die Unterschiede genauer eingehen.
Cobol C C++ Smalltalk Java
Objektorientiert
Datentypen
Zeiger
Unions/Strukturen
Einfach
Standard Library
Portable
Garbage Collection
Threading
Fehlerbehandlung
Precompiler
Interpretiert
Linker
Dynamisch
Verifizierung
Robust
Sicher
Tabelle : Java und andere Programmiersprachen (left to the reader)
5.1.3 Was fällt weg? (im Vergleich zu C/C++)
Keine Strukturen, Aufzählungstypen, Unions
Die Aufzählungstypen (z.B. enum), Strukturen und Unions können in Java, wie in jeder objektorientierten Programmiersprache, durch geeignete Klassen dargestellt werden. Deshalb sind explizite Typendefinitionen unnötig. Dieser Schritt, typedefs, enums etc. aus C++ zu entfernen war wegen der gewünschten "Kompatibilität" zu C nicht möglich. In Java wird durch diese Maßnahme die Syntax wesentlich schlanker und auch die Probleme der Namensraumvergabe wird durch die dann nötigen zugehörigen Klassen vermieden. (In C haben z.B. alle enum Typen einen eigenen, gemeinsamen Namensraum)
Keine Funktionen
Alleinstehende Funktionen, die nicht Methoden einer Klasse sind, werden nicht unterstützt. Das vermeidet Mehrdeutigkeiten und Widersprüche in der Klassenhierarchie. Java unterstützt Klassenmethoden und Klassenvariablen, wodurch alleinstehende Funktionen unnötig werden.
Keine Header Files
In Java werden die Klassen komplett in einem File Codiert. Header Files wie in C gibt es nicht. Zu jeder Klasse wird ein eigenes Klassenname.class File erzeugt. Dadurch kann es z.B. nicht mehr vorkommen, daß durch Änderungen in einer Zentralen Klasse in einem Header File das gesamte Projekt neu Übersetzt werden muß. Der Einsatz von Java macht Hilfsmittel wie make und trickreiche Compilerfeatures, die versuchen dieses Problem zu minimieren unnötig.
Kein Überladen von Operatoren
Java unterstützt kein Operator Overloading. Diese Möglichkeit war bzw. ist schon immer umstritten. Sun hat der Regel der Einfachheit und Klarheit Vorrang gegeben. Die Möglichkeiten des Operator Overloadings kann durch Klassenmethoden einfach ersetzt werden.
Kein Precompiler (z.B. #DEFINE)
Precompiler, wie man sie von C oder C++ her kennt, werden von Java nicht eingesetzt. Der durchgängig objektorientierte Ansatz soll einen Precompiler unnötig machen. Globale Definitionen von Konstanten können als Klassenvariablen (static) realisiert werden. Dadurch bekommen die Konstanten auch einen eigenen Namensraum, was widersprüchliche Bezeichnernamen ausschließt. Diverse Tricks und auch Fehlerquellen werden so ausgeschlossen.
Keine vage definierte Datentypen
In Java sind die primitiven Datentypen, anders als in C vollständig definiert. So ist ein int immer 32 Bit breit und mit Vorzeichen behaftet. Es gibt anders als in C feste Definitionen für die Basis Datentypen. Die übrigens die einzigen Typen sind die keine Klasse darstellen. Durch Vererbung können ihnen jedoch weitere Methoden zugeordnet werden.
Die direkte Implementierung von Basis Datentypen in die Programmiersprache verbessern das Laufzeitverhalten, gegenüber Typenlosen Programmiersprachen wie zum Beispiel Smalltalk, enorm.
Keine (expliziten) Pointer und keine Pointerarithmetik
Java hat zum Ziel, eine möglichst sichere Laufzeitumgebung zur Verfügung zu stellen. Aufgrund der Möglichkeit, komplexe Strukturen mit Hilfe von Klassenhierarchien darzustellen, ist Java nicht auf Pointerarithmetik angewiesen. In Java gibt es generell keine expliziten Pointer, womit ein weiterer Großteil der Fehlermöglichkeiten herkömmlicher C und C++ Programme ausgeschlossen werden.
Keine vargs (freie Argumentenanzahl)
Java unterstützt keine Funktionen mit variabler Argumentenanzahl wie es z.B. in C bei der Funktion printf verwendet wird. Auch hier stellt der objektorientierte Ansatz geeignetere und weniger fehlerträchtige Möglichkeiten zur Verfügung (wie es schon in C++ mit cout realisiert wird).
Keine Mehrfachvererbung
Die gewaltigen Probleme die durch den Einsatz von Mehrfachvererbungen auftreten können sind dadurch umgangen werden, daß es diese Möglichkeit nicht gibt. Durch den Einsatz von Interfaces die einen Satz von Schnittstellenmethoden definieren, die in der Klasse implementiert werden, wird eine weitgehend vergleichbare Funktionalität ohne die bekannten Probleme erreicht. Diese Interfaces wurden den protocols in Objective C nachempfunden.
Kein Semikolon oder doch Semikolon
Beim Design von Java wurde darauf geachtet, daß der Programmierer nicht mit irgendwelchen "; erwartet" Fehlermeldungen zu kämpfen hat. Wo es die Grammatik erlaubt ist der ";" optional oder kann beliebig oft gesetzt werden. Bei der Entwicklung der Sprache wurde auch darauf geachtet, das der Compiler die Möglichkeit hat Fehler genau zu lokalisieren. Die in C übliche Fehlermeldung mit Verweis auf eine Zeile die auf die eigentlich fehlerhafte Zeile mit fehlendem Semikolon folgt sollte in Java nicht vorkommen.
5.1.4 Speicherverwaltung
Als erste Besonderheit, insbesondere für nicht Smalltalk Programmierer ist das Konzept der Speicherverwaltung in Java zu nennen. In Java gibt es keinen Heap auf dem dynamische Daten allociert werden, also auch kein malloc oder mfree. Vielmehr sorgt die Java Laufzeitumgebung selbst dafür, das nicht mehr benötigte Objekte automatisch freigegeben werden. Dazu trägt jedes Objekt einen Zähler mit sich, wie viele Verweise auf das Objekt noch existieren.
Die Arbeit selbst dafür zu sorgen das Objekte rechtzeitig freigegeben werden, die z.B. in C++ bei komplexeren Programmen extreme Ausmaße annimmt entfällt also völlig. Man spricht von einem Garbage Collector. In Java läuft dieser Garbage Collector in einem eigenen Task mit niederer Priorität, das Aufräumen wird also im Hintergrund erledigt.
Speicherleichen, also Objekte die nicht mehr benötigt werden, deren Speicher jedoch nicht freigegeben wurde gehören automatisch der Vergangenheit an. Es kann auch nicht mehr vorkommen das eine Referenz auf ein nicht mehr allociertes Objekt existiert, was bei C und C++ zu häufigen Fehlern geführt hat (z.B. eine durch eine lokale Funktion deklarierte Variable wird per Pointer dem Aufrufer bekanntgegeben).
Dieses Konzept tritt nicht nur auf Objekte sondern auch für Klassen in Kraft, da Klassen in Java nichts anderes sind als von der Klasse Objekt abgeleitete Objekte. Das heißt insbesondere das zur Laufzeit eines Programms nur die Klassen im Hauptspeicher gehalten werden die auch wirklich gebraucht werden. Das hat zur Folge, daß beim Programmstart zunächst nur die Basisklassen z.B. der awt Library geladen werden, was allerdings auf Grund des dynamischen Linkvorgangs, der gleichzeitig einsetzt merklich Zeit in Anspruch nimmt.
5.1.5 Threads
Java verwendet selbst z.B. zur Realisierung der Speicherverwaltung Threads und es bietet dem Programmierer Klassen und Methoden zur Threadbildung zur Verfügung. Threads ermöglichen das parallele Ausführen einzelner Programmteile. Bei GUI basierenden Systemen ist es z.B. wichtig das verschiedene Aufgaben parallel erledigt werden. So will der Anwender in der Menüstruktur blättern, während in einem Fenster Berechnungen ausgeführt werden und in einem anderen gerade eine Grafik aufgebaut wird.
Bei Java muß sich der Programmierer nicht mehr mit den Besonderheiten der Zielplatform auseinandersetzen und er muß auch keine Bedenken haben ob die standard Library Funktionen reentredant (sprich mehrfach gleichzeitig aufgerufen werden dürfen) sind. Er bekommt durch Java einheitliche Methoden zur Synchronisation von Threads und zur Kommunikation zwischen verschiedenen Threads zur Verfügung gestellt. Durch den Modifizierer synchronized können Methoden eines Objekts gegen mehrfachen parallelen Aufruf geschützt werden. Ein in der Java Laufzeitumgebung implementierter Monitor überwacht dann das diese Methoden des Objekts nicht parallel sondern seriell Ausgeführt werden. Generell sollten alle Methoden die Objektatribute verändern als synchronized deklariert werden.
Die Standardbibliothek ist vollständig "Threadfest", das heißt Methoden kann uneingeschränkt mehrfach parallel aufgerufen werden.
5.1.6 Benennungskonventionen
Wie schon mehrfach erwähnt werden in Java Klassen unter ihrem Realnamen abgelegt. Dadurch muß man beachten, daß ein File mit dem Namen test.java nach der Compilierung unter Umständen mehrere Files erzeugt die zum Beispiel klasse1.class, klasse2.class etc. heißen. Zum Auffinden der Klassen wird vom ClassLoader der Klassen eine bestimmte Strategie verfolgt (wie Eingangs erwähnt kann der ClassLoader auch überladen werden und dadurch sein Verhalten verändert werden). Klassen werden zu sogenannten Packages zusammengefaßt. Bestes Beispiel sind die standard Librarys deren Namen alle mit dem Prefix java. beginnen. Um den Anspruch an die Dateisysteme nicht übergebühr zu erhöhen wird zum Beispiel für die Klasse java.awt.list der Filenamen list.class Verzeichnis .\\java\\awt\\ verwendet.
Inzwischen ist man dazu übergegangen die kompletten Librarys in einem Archiv zu speichern (CLASSES.ZIP). Dieses File darf bei der Installation von Java keinesfalls ausgepackt werden.
Zur Benennung von Klassen die (Inter-) Netz weit bekannt sein sollen, gilt die Konvention als Prefix der Klassen den eigenen URL zu verwenden (dadurch wäre es mit einem geeigneten ClassLoader möglich Klassen automatisch in der aktuellsten verfügbaren Version vom durch den URL zu identifizierenden Server zu Laden). Die Problematik der unter Umständen recht langen Klassennamen (de.fh-furtwangen.ask.katze.libs.car.class) wird derzeit heftig diskutiert und ist auch reichlich umstritten.
5.1.7 Datentypen und Strukturen
In Java gibt es folgende grundlegende Basis Datentypen:
. byte 8 Bit Zahlenwert (-128..127)
. short 16 Bit Zahlenwert
. int 32 Bit Zahlenwert
. long 64 Bit Zahlenwert
. float 32 Bit IEEE 754 Fließkommazahl
. double 64 Bit IEEE 754 Fließkommazahl
. char 16 Bit Unicode Zeichen
. boolean "echter" 1 Bit Wert
. Arrays
. String Unicode String
Dabei kommt der Programmierer nicht mit den Endiantypen der numerischen Variablen in Berührung. Was z.B. unter C zu Problemen beim Dateiaustausch führt.
String ist in Java ein echter Datentyp und nicht wie in C ein künstliches Array von Zeichen. Allerdings sind einige Methoden zur Stringmanipulation in einer Klasse der Standard Library gekapselt.
5.1.8 Die Syntax, eine Übersicht
Die Kontrollstrukturen, Schleifen und Operatoren sind weitgehend die von C oder C++ her bekannten Konstrukte. Lediglich bei den Operatoren mußte, da es keine vorzeichenlosen Zahlen gibt der >>> Operator eingefügt werden, der eine Zahl bitweise nach rechts Schiebt und von rechts Nullen nach schiebt. Im Gegensatz zum >> Operator, der das Vorzeichenbit nach schiebt. In C wurde dies anhand dessen entschieden, ob der Zahlenwert vorzeichenbehaftet war oder nicht.
Auf der nächsten Seite befindet sich die, bis auf die kursiv dargestellten Symbole DocComment, Identifier, Number, String und Character komplette Syntaxbeschreibung der Programmiersprache Java. Die Syntax ist trotz der Objektorientiertheit nicht wesentlich Komplexer als die der Programmiersprache C. Die Fett dargestellten Symbole sind Zeichen wie sie im Quelltext erscheinen. Folgende Notation wird für die Grammatik verwendet:
Ausdruck = Metaausdruck; "|" steht für Alternativen, (...) für Gruppierungen, ? für kein oder einmaliges Auftreten und * für kein oder mehrmaliges Auftreten.
CompilationUnit= PackageStatement? ImportStatement* TypeDeclaration* ;
PackageStatement= package PackageName ; ;
ImportStatement= import PackageName . * ;| import ( ClassName | InterfaceName ); ;
TypeDeclaration= ClassDeclaration | InterfaceDeclaration | ; ;
ClassDeclaration = Modifier* class Identifier (extends ClassName)? (implements InterfaceName (, InterfaceName)*)? { FieldDeclaration* } ;
InterfaceDeclaration = Modifier* interface Identifier (extends InterfaceName (, InterfaceName)*)? { FieldDeclaration* } ;
FieldDeclaration = DocComment? MethodDeclaration | DocComment? ConstructorDeclaration | DocComment? VariableDeclaration | StaticInitializer | ; ;
MethodDeclaration = Modifier* Type Identifier ( ParameterList? ) ( [ ] )* ( { Statement* } | ;) ;
ConstructorDeclaration = Modifier* Identifier ( ParameterList? ) { Statement* } ;
VariableDeclaration= Modifier* Type VariableDeclarator (, VariableDeclarator)* ; ;
VariableDeclarator= Identifier ([ ])* (= VariableInitializer)? ;
VariableInitializer= Expression | { ( VariableInitializer ( , VariableInitializer )* ,? )? } ;
StaticInitializer= static { Statement* } ;
ParameterList = Parameter (, Parameter)* ;
Parameter = TypeSpecifier Identifier ([ ])* ;
Statement = VariableDeclaration | Expression ; | { Statement* } | if ( Expression ) Statement (else Statement)? | while ( Expression ) Statement | do Statement while ( Expression ) ; | try Statement (catch ( Parameter ) Statement)* (finally Statement)? | synchronized ( Expression ) Statement | return Expression? ; | throw Expression ; | switch ( Expression ) { Statement* } | case Expression : | default; | Identifier : Statement | break Identifier? ; | continue Identifier? ; | ; ;
BiOp= + | - | * | / | % | ^ | & | | | && | || | > | >>> | = | += | -= | *= | /= | %= | ^= | &= | |= | = | >>>= | < | > | = | == | != | . | , ;
Expression= Expression BiOp Expression | Expression instanceof ( ClassName | InterfaceName ) | Expression ? Expression : Expression | Expression [ Expression ] | ++ Expression | -- Expression | Expression ++ | Expression -- | - Expression | ! Expression | ~ Expression | ( Expression ) | ( Type ) Expression | Expression ( ArgList? ) | new ClassName ( ArgList?) | new TypeSpecifier ( [ Expression ] )+ ([ ])* | new ( Expression ) | true | false | null | super | this | Identifier | Number | String | Character ;
ArgList = Expression (, Expression )* ;
Type = TypeSpecifier ([ ])* ;
TypeSpecifier= boolean | byte | char | short | int | float | long | double | ClassName | InterfaceName ;
Modifier= public | private | protected | static | final | native | synchronized | abstract | threadsafe | transient ;
PackageName= Identifier | PackageName . Identifier ;
ClassName= Identifier | PackageName . Identifier ;
InterfaceName= Identifier | PackageName . Identifier ;
Java läßt für Bezeichner (Identifier) Zeichen aus dem Unicode zu, das heißt, daß z.B. auch Umlaute in Namen vorkommen können. Diese Möglichkeit bereitet allerdings noch etlichen Dateisystemen Probleme, da die Klassennamen direkt in *.class Files abgelegt werden, daher ist bei der Benennung der Klassen darauf zu achten nur ASCII Zeichen zu verwenden, die auch in üblichen Dateisystemen verwendet werden dürfen. Da einige Betriebsysteme etwas lausig mit dem Vergleich von Dateinamen umgehen (Namentlich z.B. WIN95) sollte auch darauf geachtete werden, daß sich Klassen nicht nur durch Groß- und Kleinschreibung unterscheiden, was in Java generell möglich ist.
Zahlen (Number) werden wie in C üblich dargestellt. char ist immer ein 16Bit Unicode Wert, der entsprechend dargestellt wird 7 Bit ASCII Werte werden direkt in ihre Unicode Entsprechungen transformiert.
Strings werden wie in C üblich durch doppelte Hochkomma eingeschlossen dargestellt. Für die Darstellung von Unicode Zeichen gibt es eine spezielle Escape Darstellung.
Bleiben noch die DocComments, mittels des zur Java Entwicklungsumgebung gehörenden Dokumentencompilers kann aus Java Quelltext eine Dokumentation der Klassenhierarchie und der Klasseninterfaces erstellt werden. Sun hat aus der Not, das der Quelltext sich schneller verändert als die Dokumentation angepaßt wird eine Tugend gemacht und ermöglicht die Dokumentation des Codes direkt im Programmcode unterzubringen.
Um textuelle Beschreibungen in diese Dokumentation einfließen zu lassen gibt es eine spezielle Kommentarklammerung. Der Text zwischen /** und */ wird zur Beschreibung des darauffolgenden Codes (in der Regel eine Definition) verwendet und Automatisch eingebunden. Das erzeugte Dokument wird im HTML Format ausgegeben. Es ist auch möglich im Kommentar HTML Tags zu verwenden die dann in das Dokument übernommen werden. Hyperlinks ermöglichen es die Verschiedenen Hierarchiestufen der Klassen zu verfolgen. In den Kommentaren können dadurch auch HTML Tags z.B. zur Hervorhebung genutzt werden.
5.1.9 Compiler
Der Java Compiler (javac) überprüft den Quelltext und erzeugt aus den *.java Files die entsprechenden *.class Files der Klassen die darin Implementiert sind. In der aktuellen JDK Version (1.01) muß zwischen dem Dateinamen des Quelltextes und den der erzeugten Class Dateien kein Zusammenhang mehr bestehen. In früheren Versionen mußte in der Quelltextdatei eine Klasse mit dem Namen der Datei enthalten sein. Bei der Compilation wird der Quelltext bereits, soweit möglich, auf Fehler untersucht und in den von der Virtuellen Maschine zu interpretierenden Bytecode umgewandelt. Identifizierer, die zum Beispiel für den Zugriff auf andere Klassen benötigt werden bleiben dabei in Klarschrift erhalten und werden erst vom Interpreter in (physische) Adressen umgesetzt.
Zum Compiler gehört auch javadoc, der aus Java Quellfiles ein HTML Dokument der Klassenhierarchien und der Klassen Methoden und Attribute erzeugt. Dazu werden auch die Texte aus den Dokumentkommentaren verwertet.
In Suns JDK (Java Development Kit) ist auch ein Compiler namens javac_g vorhanden. Dieser hat die gleiche Funktionalität wie der javac Compiler, er wurde jedoch mit Debuging Informationen übersetzt und ermöglicht so das leichtere Auffinden von Fehlern innerhalb des Compilers. Der Compiler selbst verwendet die Java Librarys, daher ist die Größe des Programms überraschend gering.
5.1.10 Virtuelle Maschine
Die Virtuelle Maschine interpretiert den Java Bytecode. Erst sie löst externe Referenzen auf, indem sie den ClassLoader, der die benötigte Klasse bei Bedarf sucht und in den Hauptspeicher lädt, aufruft und die Klartextnamen durch Adressreferenzen ersetzt.
Auf einem Computer bzw. Betriebssystem auf dem diese Virtuelle Maschine realisiert ist können alle Java Programme laufen. Dabei ist keine Neucompilierung des Quelltextes nötig. Vor der Instanziierung einer Klasse werden dabei Laufzeitprüfungen und eine Verifikation vorgenommen, welche die Sicherheit des Programms gewährleisten sollen (dazu später mehr).
5.1.11 Linker?
In Java gibt es keinen Linker im ursprünglichen Sinne, wie schon oben Beschrieben wird jede Klasse in ein einzelnes File gespeichert. Der ClassLoader lädt die Klassen automatisch bei Bedarf (und erst dann) in den Hauptspeicher. Gibt es keine Referenz bzw. Instanz der Klasse mehr, so wird der Speicher wieder freigegeben.
Der Klassenlader kann dabei durch eigene Klassen überladen werden und ermöglicht so z.B. das auffinden einzelner Klassen über die Grenzen des lokalen Rechners hinweg.
Der Linkprozeß findet also erst zur Laufzeit des Programms statt. Eine Unterscheidung, wie in C++ zwischen frühem und spätem Linken existiert nicht.
|
