4.2 Editieren - Compilieren
 
Interpreter - Compiler Ein Interpreter ist selber ein Programm, der den Quelltext in dem Sinne ausführt, dass Zeile für Zeile eines Programms in einen auf der Maschine lauffähigen, so genannten Maschinencode übersetzt und vom Rechner abarbeiten lässt. Das hat zur Folge, dass eine Zeile, die in einer Schleife z.B. 100 mal abgearbeitet werden soll, 100 mal übersetzt werden muss. Das kostet viel Zeit. Zudem können Syntaxfehler erst beim Laufen lassen des Programms gefunden werden.

Im Gegensatz zum Interpreter wird der Quelltext vom Compiler auf einmal in einen Maschinencode übersetzt und kann dann schnell abgearbeitet werden. Fehler werden nicht erst beim Laufen lassen des Programms, sondern bereits beim Übersetzten aufgespürt.
 

Java VM Der Java-Compiler ist kein vollständiger Compiler, da sein Output kein lauffähiges Programm mehr ist, sonder ein sog. Bytecode, der von einem Interpreter abgearbeitet wird. Er hat den Vorteil, dass Syntax-Fehler bereits beim Kompilieren gefunden werden. Die bei dieser Technologie gewonnene Plattformunabhängigkeit führt beim Starten eines Javaprogramms zu einer Verzögerung. Die Virtuelle Maschine, die den Java-Bytekode ausführen soll, kompiliert den Bytekode zu einem lauffähigen Programm. Wir sprechen auch deshalb von einem 'Just-in-time-Compiler'.

Was den Java-Compiler so interessant macht, ist seine Plattformunahängigkeit. Was bedeutet dies?
 

Übliche Compiler - Lopgik Ein Quellcode, der in einer Sprache geschrieben ist, muss von einem rechnerspezifischen Compiler in einen auf der jeweiligen Maschine lauffähigen Maschinencode übersetzt werde. D.h. Ein in z.B. C++ geschriebener Quelltext muss von jeweils verschiedenen Compilern für die verschiedenen Plattformen übersetzt werden. Das kostet viel Zeit und Geld. Man muss für eine Sprache für jede Plattform einen Compiler entwickeln. Dafür hat man einen Code, der auf den einzelnen Maschinen schnell abgearbeitet wird.

 

Die "neue" Compiler - Logk Aus einem Quelltext einer plattformenübergreifenden Sprache wie Java, erzeugen plattformenabhängige Compiler einen standardisierten Bytecode, der für alle Maschinentypen gleich ist. Virtuelle Java-Maschinen (VM) haben dann nur noch den Bytecode zu interpretieren. Es ist also Aufgabe der Plattformenhersteller, ihren Kunden eine Java VM zur Verfügung zu stellen. Der Javaprogrammierer arbeitet somit auf einer beliebigen Maschine und verkauft seinen plattformenunabhängigen Byte-Code. Folgen sind Kosten- und Zeitersparnis und nicht zu vergessen die Möglichkeit Java im Internet einzusetzen. Die Java VM muss dazu lediglich in den Browser eingebunden sein.

 

 

Für eine Maschine ist also nur ein Compiler notwendig, der den standardisierten Byte-Code erzeugt.

 

Vom Plan zum Produkt Für den Informatikalltag interessiert uns, wie kommen wir vom Plan eines Programms zum Produkt.
  Das nebenstehende Ablaufdiagramm verdeutlich die Schritte, die ein Softwareentwickler und
-programmierer gehen muss, um vom Plan bis zum Endprodukt zu kommen. Am Anfang steht die Planung, die für sich genommen je nach Projekt so umfangreich und komplex sein kann, dass speziell ausgebildete Leute diese Aufgabe übernehmen. Das Rechteck mit der Inschrift 'Beginn' markiert den eigentlichen Startpunkt des Programmierers. Er schreibt (=editiert) den Quelltext und lässt ihn anschließend vom Compiler übersetzen. Sehr häufig enthält der Quellkode, nicht selten durch Schreibfehler verursachte, Syntaxfehler. In diesem Fall muss man immer wieder zurückkehren und den Text bearbeiten, bis er syntaktisch korrekt ist und vom Compiler vollständig übersetzt wird. Danach lässt man das Programm laufen. Dabei kann es wieder zu Fehler kommen, den so genannten Laufzeitfehler. Auch in diesen Fällen muss man den Quelltext bearbeiten. Die Fehler liegen häufig darin, dass Datenstrukturen nicht korrekt verwaltet werden (z.B. unbeabsichtigte Division durch null). Treten schließlich keine Laufzeitfehler mehr auf, kann das Programm trotzdem nicht das liefern, was es oll. Man sagt, es ist semantisch nicht korrekt. Jetzt ist der Fehler in der Planung zu suchen. Wir sehen, es gibt viele Möglichkeiten, dass ein Programm 'nicht tut'. Sorgfältige Planung und diszipliniertes Programmieren zahlt sich auf Dauer sicherlich aus. 
zu 4.3 Übungen und Aufgaben
zur Startseite www.pohlig.de  (C) MPohlig 2004