2.8.2 Editieren - Kompilieren
 
Interpreter - Kompiler 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 Maschinenkode ü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 Kompiler auf einmal in einen Maschinenkode ü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-Kompiler ist kein vollständiger Kompiler, da sein Output kein lauffähiges Programm mehr ist, sonder ein sog. Bytekode, 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-Kompiler so interessant macht, ist seine Plattformunabhängigkeit. Was bedeutet dies?
 
Übliche Kompiler - Lopgik Ein Quellkode, der in einer Sprache geschrieben ist, muss von einem rechnerspezifischen Kompiler in einen auf der jeweiligen Maschine lauffähigen Maschinenkode übersetzt werde. D.h. Ein in z.B. C++ geschriebener Quelltext muss von jeweils verschiedenen Kompilern für die verschiedenen Plattformen übersetzt werden. Das kostet viel Zeit und Geld. Man muss für eine Sprache für jede Plattform einen Kompiler entwickeln. Dafür hat man einen Kode, der auf den einzelnen Maschinen schnell abgearbeitet wird.

 
Die "neue" Kompiler - Logk Aus einem Quelltext einer plattformenübergreifenden Sprache wie Java, erzeugen plattformenabhängige Kompiler einen standardisierten Bytekode, der für alle Maschinentypen gleich ist. Virtuelle Java-Maschinen (VM) haben dann nur noch den Bytekode zu interpretieren. Es ist also Aufgabe der Plattformenhersteller, ihren Kunden eine Java VM zur Verfügung zu stellen. Der Java-Programmierer arbeitet somit auf einer beliebigen Maschine und verkauft seinen plattformenunabhängigen Byte-Kode. 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 Kompiler notwendig, der den standardisierten Byte-Kode 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 Kompiler ü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 Kompiler 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 2.8.3 Übungen
zur Startseite www.pohlig.de  (C) MPohlig 2006