Autor: 'Kriz'
Mit dieser kleinen Tutorialreihe möchte ich euch die Programmiersprache Java etwas näher vorstellen. Ich erweitere das Tutorial nach und nach mit jeweils einem neuen Abschnitt. Let's go Java…
Tutorial #1 - Themenübersicht:
Java ist eine mehrzweckfähige, objektorientierte und portable Programmiersprache. Informatisch gesehen gehört Java zu der 3GL (3rd generation language) Programmiersprachenfamilie. Diese definiert die Klasse der Hochsprachen.
Java ist hauptsächlich für die Darstellung in grafisch orientierten Betriebssystemumgebungen und Webbrowsern ausgelegt worden. Java verfügt daher über Programmbibliotheken, die das Anzeigen von Fenstern, Buttons usw. ermöglichen. Traditionelle Konsolenanwendungen sind aber auch (meistens) möglich.
Java ist vollkommen objektorientiert ausgelegt worden, d.h. in Java gibt es definitiv keine globalen Funktionen, Variablen, Konstanten oder andere Datenelemente. Der gesamte Code wird in Klassen implementiert, wobei jede Klasse ein isoliertes Objekt darstellt, daß mit anderen Objekten außerhalb seiner Grenzen kommunizieren kann.
Der Sprachumfang von Java enthält 51 reservierte Schlüsselwörter, die bei der Programmierung vom Benutzer nicht als Variablenbezeichner o.ä. benutzt werden dürfen. Die allgemeine Syntax von Java ist stark an C++ angelehnt, d.h. C++ Programmierer werden sich in Java recht schnell einarbeiten können.
Java hat ein dogmatisches Designziel, daß kaum von einer Programmiersprache derartig jemals umgesetzt worden konnte: Portabilität. Java-Programme sind in der Regel zu 95% von einem Computer auf einen anderen portierbar. Dazu muß man wissen, daß Java nicht kompiliert wird (wie z.B. C++), sondern interpretiert.
Dabei wird aber nicht der Java-Programmcode interpretiert, sondern eine kompilierte Metaform des Programmcodes. Diese Metaform heißt Java Bytecode. Der Java Bytecode ist die binäre Abbildung eines regulären Java-Programms. Der Bytecode besteht intern aus einer Kette aneinandergereihter Bytes (daher der Name). Auftreten und Kombinationen aus den verschiedenen Bytes ergeben dann wiederum die Abbildungen des ursprünglichen Java-Programmcodes.
Der Java Bytecode (oder meist auch nur Bytecode genannt) wird von fast allen Computern dieser Welt verstanden, da das Byte die Basis aller mittleren und modernen Computerarchitekturen darstellt. Allerdings kann ein regulärer Prozessor den Bytecode nicht verstehen (außer es handelt sich um einen der ominösen Java-CPUs), sondern ein virtueller Prozessor muß ihm diese Arbeit abnehmen und den Bytecode in prozessorverständliche Maschinenbefehle umwandeln. Dieser virtuelle Prozessor ist dabei ein Programm, welches extra für das benutzte Betriebssystem geschrieben worden ist und allgemein als Java Virtual Machine, kurz Java-VM, bekannt geworden ist. Die Java-VM ist ein Interpreter, der den Bytecode in Quasi-Echtzeit erkennen und ausführen kann.
Daher muß auf dem Zielcomputer nur eine Java-VM installiert sein, um (fast) jedes Java-Programm dort zum Laufen bringen zu können. Alle modernen und populären Betriebssysteme besitzen eine Java-VM bzw. ist eine Java-VM nachträglich installierbar: Windows, Linux, Unix, MacOS, BeOS, OS/2 Warp usw.
Eine kleine Nachbemerkung zu den oben angesprochenen Java-CPUs… In den frühen Gründerjahren von Java (Mitte der 90er Jahre) boomte Java als der neue Renner unter den Programmiersprachen. In diesem euphorischen (Java) Hype kamen einige Prozessordesigner auf die Idee, daß man ja CPUs entwickeln könnte, die den Bytecode als native Maschinenbefehle ausführen könnten. Dadurch wären sowohl ganze Betriebssysteme als auch Anwendungen auf Java-Basis möglich gewesen. Allerdings blieb der Erfolg dieser Java-CPUs außen vor und die Sache geriet schnell wieder ins Hintertreffen. Es gibt zwar einige Java-CPUs auf dem Markt, allerdings werden diese nur als sogenannte embedded systems verhökert und sind praktisch nur für die Hardwareindustrie interessant.
Durch die Einführung der Java-VM und des Bytecodes als portables Medium zwischen den verschiedensten Computer- und Betriebssystemen kann man recht einfach und preisgünstig Programme entwickeln und sofort auf allen kompatiblen Systemen laufen lassen.
Ein besonderer Aspekt von Java ist allerdings nicht die Entwicklung normaler Programme als solche, sondern die Entwicklung von sogenannten Applets (application snippets). Applets sind Programme für das Internet bzw. Programme für das World Wide Web. Applets werden auch nicht durch die systemeigene Java-VM ausgeführt, sondern durch eine implementierte Browser-Java-VM. Das bedeutet, daß Applets von den Browsern selbst ausgeführt werden und somit die Möglichkeit besteht, echte Programme auf Webseiten zur Verfügung zu stellen. Dieses Feature von Java brachte ihr auch den Beinamen Internet Programmiersprache ein. Durch Applets ist es erst möglich geworden, Programme über das Internet zu verschicken und sofort ausführen zu lassen.
Applets sind Applikationsschnipsel, also de facto gestutzte Java-Programme. Dieser Begriff täuscht oft vor, daß Applets nur abgesägte Java-Applikationen zu sein scheinen, was aber nicht so ist. Applets unterliegen einem sehr strengen Sicherheitsmechanismus, damit ein aktives Applet im Browser keinen Schaden am Betriebssystem und auf dem Computer anrichten kann. So ist es einem aktiven Applet nicht erlaubt beispielsweise andere Programme auf dem Computer zu starten, irgendeine Dateioperation durchzuführen oder andere Applets zu starten. Dieses ist das Basisverhalten aller Applets. Darüberhinaus gibt es noch die sogenannten signierten Applets, die ähnlich wie E-Mails usw. Zertifikate besitzen und beweisen können, daß sie von einer sicheren und vertrauenswürdigen Quelle stammen. Signierte Applets haben dann die Möglichkeit, alle verbotenen Operationen auf das Computersystem anzuwenden. Somit könnte man beispielsweise einen appletbasierten FTP-Manager anbieten, der direkt Daten von der Festplatte auf einen Webspace transferieren könnte. Da das Zertifizieren (bzw. Signieren) eines Applets nur durch authorisierte Vergabestellen erfolgt, kann jedes signierte Applet auf seinen Herkunft hin genau geprüft werden und u.U. ein schwarzes Schaf sofort entlarven.
Das wären erstmal die wichtigsten Eigenschaften rund um Java, über die man Bescheid wissen sollte. Im nächsten Abschnitt erzähle ich kurz was über die Geschichte von Java.
Java war ursprünglich einmal eine interaktive Kommunikationssprache für die Unterhaltungs- und Haushaltselektronik. Man wollte Anfang der 90er Jahre mit Hilfe von Java, das früher noch OAK hieß, einen Standard schaffen für das große Ziel des vernetzten Haushalts.
OAK sollte dabei als Schnittstelle zwischen allen OAK-kompatiblen Geräten im Haushalt dienen und die reibungslose Kommunikation gewährleisten. Dabei setzte man neben dem bereits angesprochenem Interpreterverhalten auch auf ein zweites Feature, nämlich die einheitliche Mensch-Maschinen Visualisierung. Als interaktive Schnittstelle zwischen dem Menschen und dem OAK-Gerät sollte eine standardisierte Benutzeroberfläche erfunden werden, die von der Funktion und vom Aussehen her auf allen OAK-kompatiblen Geräten gleich sein sollte. Diese GUI wurde auch komplett entwickelt und für OAK bereitgestellt bzw. als Bestandteil von OAK implementiert.
Diese OAK-Geschichte war ein Projekt der Firma SUN Computers in den USA. Man hatte viel Hoffnung in die Entwicklung und letztendlich auch in die Lizensierungspolitik für OAK gesetzt, vor allem nachdem in den 90er Jahren die Technik im Mikroprozessorbau soweit vorangeschritten war, daß man über kleine und kompakte OAK-Hardware nachdenken konnte. Leider (oder Gottseidank?!?) wurde das OAK Konzept niemals realisiert und gelangte daher auch niemals auf den Markt. Stattdessen hätte SUN beinahe einen anderen, wichtigen Trend verpennt: Das Internet.
Während alle anderen großen Softwarehersteller bereits einen grafischen Browser für das neue Medium Internet im Angebot hatten, hatte SUN eigentlich garnichts anzubieten. Das schmeckte den Bossen von SUN überhaupt nicht und man erwog auf der Basis von OAK einen eigenen Webbrowser zu entwickeln und zu verkaufen. Schließlich hatte man ja viel Geld und Zeit für die Entwicklung eines systemunabhängigen Kommunikationsmittels investiert und so einfach wollte man es auch nicht wieder fallen lassen.
Allerdings entpuppte sich der SUN Webbrowser als Flop, da er langsam und inkonsistent arbeitete. Per Zufall wurde die ebenfalls nagelneue Webfirma Netscape auf das SUN'sche Webbrowserprojekt aufmerksam. Genauer gesagt interessierte sich Netscape für die Technologie hinter dem Webbrowser. Man fand schnell heraus, daß das ehemalige OAK-Projekt einen bis dato unbekannten Markt eröffnen könnte: Programme über das Internet veschicken und ausführen lassen.
Aus OAK wurde dann Java, eine Anspielung an den SUN Webbrowser HotJava (in etwa: heißer Kaffee, ein Phänomen in den USA, daß man sich in jedem Starbuck's Coffee Laden ruhig mal antun kann → regelmäßig Schnauze verbrennen beim ersten Schluck). Netscape lizensierte sich die Java-Technologie und brachte mit dem Netscape 2.0 den weltweit ersten Webbrowser hervor, der in der Lage war Java-Applets auszuführen.
Sämtliche Details wie Entwicklungsumgebungen für Java und Programmiertools wurden praktisch über Nacht die heißbegehrtesten Objekte in den Newsgroups rund um den Erdball! Das war im Jahre 1995, das offizielle Geburtsjahr von Java.
Java wird offiziell von JavaSoft verteilt und gepflegt. JavaSoft ist eine Unterfirma von SUN Computers. Auf der offiziellen Homepage gibt es die aktuellsten News, Berichte, Artikel, Downloads und Versionen von Java. Java an sich kostet nichts außer den eigenen Onlinekosten für den Download. Sämtliche Bibliotheken, Dokumentationen und Entwicklungskits sind ausnahmslos kostenlos beziehbar. Der Sourcecode der Java-Tools ist allerdings nicht frei.
Freie Java-Versionen gibt es u.a. von GNU (Guavac).
Wenn man mit Google mal eine Suche nach Java oder Applets startet, wird man von der Zahl der Webseiten erschlagen! Es gibt sowohl Applets als auch ein Haufen Composer (Builderprogramme) sowie normale Java-Applikationen.
Hier einige Links zu Java-Seiten:
www.java.de - Stammseite der JUGD (Java User Group Deutschland e.V.)
java.seite.net - Kaffee & Kuchen (Der Oldtimer im deutschsprachigen Java-Webring)
www.javabuch.de - Downloadbares Online-Tutorial von Guido Krüger (sehr gut!)
Während der Erfinder von C++, Bjarne Stroustrup, C++ überhaupt nicht gerne mit anderen Sprachen oder gar Java vergleicht (die Gründe kann man auf seiner Webseite nachlesen), drängen die Javaner geradezu darauf.
Ich möchte hier jetzt aber keine detaillierte Vergleichsliste aufstellen, sondern die Kernpunkte beider Sprachen gegenüberstellen und bewerten:
Java und C++ sind beides objektorientierte Sprachen. Java dagegen hat den Anspruch sich als vollständig objektorientierte Sprache zu bezeichnen, während C++ sich dagegen nur als semi objektorientierte Sprache präsentieren kann. Während C++ als offizielle Erweiterung von C dessen gesamten Sprachumfang besitzt und C keine objektorientierte Sprache darstellt, hängt C++ irgendwo zwischen den Seilen. Während man in Java nur objektorientiert programmieren kann, erlaubt C++ durchaus auch die klassische Methode der struktuierten Programmierung.
Das ist ein Feature, welches Java nicht kennt. In C++ dagegen kann man vor dem eigentlichen Kompilieren des Programmcodes mit den sogenannten Präprozessor-Direktiven das Kompilieren ein wenig steuern. So können bestimmte Teile des Programmcodes bedingt kompiliert werden, d.h. sie werden nur dann kompiliert, wenn bestimmte Voraussetzungen oder Rahmenbedingungen erfüllt sind.
Bedingtes Kompilieren ist in Java nur teilweise möglich und mit einem erheblich größerem Aufwand verbunden, da infolge der fehlenden Direktiven alle Bedingungen mit Javas Sprachelementen selbst definiert werden müssen. Das ist gerade bei der mittlerweile erheblichen Anzahl diverser Java-Versionen ein kleines Problem, wenn man zum Ziel hat, daß bestimmte Programmcodeteile nur dann kompiliert werden sollen, wenn auch die passende Java-VM auf dem Rechner vorhanden ist. In C++ ist es dagegen mehr als simpel zu definieren, daß Programmcodeteile nur dann kompiliert werden sollen, wenn beispielsweise ein Windows kompatibler Compiler vorhanden ist usw.
Java kennt keine expliziten (ausdrücklichen) Zeiger und die darauf anwendbaren Zeigerarithmetiken. Da man bei Java davon ausgegangen war, daß gerade Zeiger die häufigste Fehlerquelle in C++ Programmen gewesen sein sollen, verzichtete man auf dieses Feature. Stattdessen arbeitet man in Java höchstens mit Referenzen (implizite Zeiger) und dann auch nur bei Objekten (Primitive Datentypen können in Java nicht referenziert werden). Wenn man bedenkt, daß Zeiger in C++ vor allem bei der dynamischen Speicherplatzerzeugung eine Rolle spielen, dann fragt man sich, wie man in Java ohne Zeiger dynamisch Speicherplatz erzeugen kann.
Nun, diese Arbeit übernimmt nachwievor der Programmierer, nur das spätere Aufräumen von benutztem Speicherplatz übernimmt Java selber (bzw. die Java-VM). Ein Hintergrundthread mit niedriger Priorität und dem Namen Garbage Collector (Müllsammler) untersucht dabei in mehr oder weniger regelmäßigen Abständen, ob bestimmte, dynamisch erzeugte Objekte noch gültig sind. Falls nicht, kickt der Garbage Collector automatisch diese Objekte aus dem Heap. Diese Arbeit ist in C++ dem Programmierer selber aufgebürdet, weshalb gerade dort die Arbeit mit dynamischen Objekten nicht ganz untrivial ist!
Auch die Technik der Schablonen ist in Java unbekannt. Da in Java der Datentyp void nicht in derselben Weise implementiert ist wie void in C++, können von Natur aus keine Schablonenklassen in Java für beliebige Objekte programmiert werden. In Java bedeutet void schlicht und einfach nichts, während in C++ void durchaus als Universaldatentyp agieren kann.
Das Fehlen von Templates in Java wird aber durch das strikte Klassenkonzept wieder halbwegs ausgebügelt. Da man aber selber bemerkt hat, daß irgendwo doch eine gewissen Schablonisierung erforderlich ist, hat man in Java für jeden primitiven Datentyp (int, float usw.) eine eigene Wrapperklasse spendiert. Da Klassen in Java Objekte sind, fügen sich die Wrapperklassen nahtlos in das Klassen-Objekt-Prinzip ein und können so von anderen Wrapperklassen schablonisiert werden. Das ist zwar auf Dauer keine echte Lösung, kann aber bei bestimmten Allgemeinklassen äußerst hilfreich sein.
Auch hier muß Java C++ den Vorzug geben. Da in C++ alle Operatoren als Methoden einer (unsichtbaren) Operatorenklasse implementiert sind, können dort auch (fast) alle Operatoren für bestimmte Datentyp-Kombinationen überladen werden. Da in Java aber alle Operatoren Bestandteil des VM-Kerns sind und fest definiert worden sind, ist dort ein Überladen von Operatoren nicht möglich. Zwar basieren einige Basisklassen (wie z.B. String oder BufferedString) nicht direkt auf primitiven Datentypen (für die in Java alle Operatoren auch abgebildet worden sind), dennoch ist es möglich mit bestimmten Operatoren bestimmte Methodenaufrufe indirekt auf ein Klassenobjekt anzuwenden (so kann man beispielsweise mit dem += Operator ein Stringliteral einem bereits vorhandenem Stringobjekt hinzufügen). Da aber diese Klassen Bestandteil der Java-Programmbibliothek sind (also quasi als Standard gelten), sind diese Operatorenüberladungen mit großer Wahrscheinlichkeit ein Hack seitens von JavaSoft und bilden daher eine irrationale Ausnahme vom sonstigen Java-Konzept.
Java ist mitunter einer der strengsten Sprachen was die Prüfung von Datentypen angeht. Die Trennung zwischen ganzzahligen, gebrochenen oder logischen Datentypen usw. ist so streng, daß die Java-VM noch nicht einmal von selbst eine Konvertierung von float nach short zuläßt, ganz einfach weil float und short zu unterschiedlichen Basisdatentypen gehören. Auch kann man nicht wie in C++ üblich eine Bedingung wie folgt mit Java realisieren:
// Bedingung in C++ int x = 2 - ( 4 / 2); // Ergibt x = 0 -> false if(x) x = 1; // Bedingung in Java int x = 2 - (4 / 2); if(!x) x = 1; // FEHLER!!!
Die Variable x ist in beiden Sprachen vom Datentyp int, also ganzzahlig. Während C++ aber innerhalb des Bedingungskörpers aus der ganzzahligen 0 ein äquivalentes, logisches false casted (umwandelt) und dadurch die Bedingung ausgewertet werden kann, meckert der Java Compiler an dieser Stelle, daß für eine logische Bedingungsprüfung auch nur ein logischer Datentyp benutzt werden darf (bzw. ein logischer Zustand). Da int aber ein ganzzahliger Typ ist, ist er inkompatibel für dieser Prüfung und erzeugt so eine Fehlermeldung. Daher kann man in Java eine solche Prüfung nur wie folgt realisieren:
// Gültige Prüfung in Java int x = 2 - (4 / 2); if(x == 0) x = 1;
Der Ausdruck x == 0 liefert schließlich einen logischen Wert (entweder true oder false) und dieser kann von der if-Bedingung akzeptiert werden.
Dieses Verhalten ist zwar löblich, aber in der erfahrenen Programmierpraxis (und ganz besonders für C++ Programmierer) ein Umstand ohne Ende. Auch ich tue mich damit immer noch sehr schwer, daß ich hier nicht einfach auf x, sondern erst x mit einem Vergleichwert prüfen lassen kann. Das ist sehr gewöhnungsbedürftig!
Interessant in diesem Zusammenhang ist übrigens auch das Deklarieren von Zahlliteralen in Java. Während C++ z.B. automatisch eine 1 in den erforderlichen Zieldatentyp konvertiert, meckert Java manchmal ganz kräftig. Bestes Beispiel:
// C++ Code long KlasseX::MethodeY(short s) { return static_cast<long>(s); }
Ein Aufruf dieser Methode mit dem Übergabewert 100 hat keinerlei Konsequenzen seitens des C++ Compilers zu folge. Anders dagegen in Java. Dort wird jeder Wert wie 100 automatisch als int-Wert definiert. Da aber int vom Wertebereich ja größer ist als short, wäre das für den Compiler ein implizites Downsizing von int-100 nach short-100. Und das macht er nicht mit. Erst wenn wir explizit ein (short)100 an diese Methode übergeben würden, würde der Compiler das akzeptieren.
Dieses eigenartige Verhalten ist nicht nur störend in Java, sondern auch meines Erachtens vollkommener Blödsinn. Da für die Datentypen byte und short in Java keine expliziten Literalidentifikatoren existieren (so wie das L oder l bei long-Werten → 127374L), zwingt Java den Programmierer immer dazu, bei solchen Methodenaufrufen einen expliziten Cast herbeizuführen. Das macht C++ nicht!
Sowas gibt es in Java nicht. Aufgrund der Syntaxstruktur von Java werden alle Methoden direkt innerhalb der Klassen deklariert und gleichzeitig definiert. Externe Deklarationen existieren in Java nicht, weshalb auch die in C++ notwendigen Headerdateien überflüssig geworden sind.
Externe Klassenmodule werden in Java als „ganzes Stück“ geladen, während in C++ als Vorgabedefinition die Headerdatei dient und aus der der Linker später die Referenzen zur Quelldatei beim Kompilieren auflöst.
In Java sind von Haus aus alle Methoden virtuell deklariert, damit die Polymorphie des Codegerüsts permanent garantiert werden kann. Das geht zu Lasten der Programmgeschwindigkeit. Nur statische und finale (konstante) Methoden sind in Java nicht-virtuell. In C++ dagegen kann man selber bestimmen, ob eine Klassenmethode virtuell sein soll oder nicht. Gerade bei kleinen C++ Klassen, die aller Vorausicht nach nicht mehr abgeleitet werden, erhöht der Verzicht auf die Virtualität von Methoden die Performance des Programms.
Da Java als interpretierte Sprache sowieso schon unter etwaigen Geschwindigkeitproblemen zu leiden hat, ist die permanente Virtualität aller nicht-statischen/-finalen Methoden ein Leistungsbremser.
Wie bereits ein paar Mal schon erwähnt, gibt es in der vollständig objektorientierten Welt von Java keine globalen Datenelemente. Selbst die obligatorische Programmeinsprungsmethode main() ist eine statische Methode innerhalb der vom Programmierer erstellten Programmhautpklasse.
C++ dagegen kennt in Anlehnung von C durchaus globale Datenelemente.
Java hat eine sehr große und sehr umfangreiche Standardbibliothek parat, da Java für die Darstellung von systemunabhängigen Fenster usw. eigene Fenstermodule benötigt. C++ dagegen basiert auf einer Mischung aus traditionellen C-Standardbibliotheken und der STL (Standard Template Library) von Hewlett-Packard, wobei es zu fast jeder C-Standardbibliothek eine enstprechende C++-Variante gibt.
Es gibt noch viele Unterschiede mehr, die aber meist nur marginaler Natur sind, sprich nicht unbedingt erwähnenswert sind. Im Laufe der Tutorialreihe werde ich eh explizit auf konkrete Unterschiede zwischen Java und C++ drauf zurückkommen.
Java kennt im Gegensatz zu C++ keine Mehrfachvererbung. Dieses Manko wurde von den Java-Designern bewußt herbeigeführt, da sie auch hier der Ansicht waren, daß Verwaltungsarbeiten bei mehrfach abgeleiteten Objekten zu kompliziert und fehlerträchtig seien. Da aber ein Objekt oftmals Eigenschaften von zwei oder mehr Objekten besitzt, mußte eine Alternative zur Mehrfachvererbung her.
Diese wurde in Form der sogenannten Interfaces realisiert. Interfaces ähneln abstrakten Klassen (was das genau ist, kommt später =) und besitzen nur die Deklarationen von Methoden sowie Konstanten. Erbt eine Klasse ein Interface, so muß es alle darin enthaltenen Methodendeklarationen implementieren, ansonsten bricht der Java-Compiler mit einer Fehlermeldung ab.
Definiert man nur Konstanten in einem Interface, dann hat man im Prinzip so was Ähnliches wie eine enum-Struktur in C++.
Java und C++ sind sich in vielen Stellen ähnlich, aber auch an anderen Stellen wieder total unterschiedlich. Daher kann man Java und C++ eigentlich kaum direkt vergleichen. Java hat viele Dinge dem Benutzer abgenommen, die in C++ zum täglichen Brot gehören. Andererseits hat Java auch wieder eine Menge Features, die C++ kaum oder garnicht kennt. Da Java speziell für den Einsatz im Internet konzipiert worden ist und C++ dagegen auf die Entwicklung stationärer Programme, hat jede der beiden Programmiersprachen genau ihren Teil der Arbeit erfüllt und muß sich daher nicht zwingend mit der anderen Sprache messen, wenn die Kriterien sowieso vollkommen unterschiedlich sind.
Wenn jemand Java mit eienr Programmiersprache vergleichen will, dann sollte er das am besten mit SmallTalk machen, denn die meisten Features von Java sind nicht von C++ entlehnt worden, sondern eben von SmallTalk.
Java wird in zwei verschiedenen Paketen ausgeliefert. Zum einen in der JRE (Java Runtime Environment) und zum anderen in dem JDK (Java Development Kit).
Die JRE ist das Basissystem für Java und erlaubt nach einer erfolgreichen Installation das Ausführen von Java-Programmen auf dem eigenen Rechner. Da die Versionen des Java-Interpreters immer wieder mal wechseln, ist man mit einer jeweiligen Neuinstallation einer aktuellen JRE immer auf dem neuesten Stand der Dinge.
Zudem kann man optional während der Installation (bei Windows und MacOS) festlegen, ob installierte Webbrowser ebenfalls indirekt durch ein Java-Plugin upgedatet werden sollen, da die hauseigenen Java-VMs der Webbrowser oftmals schon hoffnungslos veraltet sind.
Mit einer JRE kann man aber keine eigenen Java-Programme oder -Applets entwickeln. Dafür braucht es schon etwas mehr…
Das JDK ist das komplette Entwicklungskit zum Schreiben eigener Java-Programme oder -Applets. In jedem JDK ist die aktuellste JRE gleich mit enthalten, so daß man eine separate JRE nicht extra downloaden muß. Das JDK ist aber keine komplette Entwicklungsumgebung wie z.B. VisualC++ oder KDevelop ect.! Dem JDK sind nur alle nötigen Tools und Programme beigelegt worden, um das Programmieren eigener Java-Programme zu ermöglichen.
Passende IDEs (Integrated Development Environments) gibt es allerdings für Java eher selten. Außer den großen, populären Java-IDE Herstellern wie Borland oder Microsoft ist der Markt an Java-IDEs eher dünn gesät. Die damals populäre IDE KAWA von TekTools gibt es zum Beispiel nicht mehr, seitdem TekTool von Macromedia vor 4 Jahren aufgekauft worden ist…
Aber ein guter Texteditor (vorzugweise mit Syntax-Highlighting) sowie eine optionale Möglichkeit zum Direktzugriff auf die Systemkonsole (MS-DOS, BaSH-Shell ect.) reichen vollkommen aus, um Java in den Griff zu bekommen.
Wie bereits erwähnt sind Applets spezielle Java-Programme zur Ausführung auf allen javafähigen Webbrowsern. Bis auf die eingeschränkenden Sicherheitsrestriktionen normaler Applets sind Applets vollwertige, objektorientierte Programme, die auf einer Webseite im HTML-Format gestartet und bedient werden können. Da Applets ja der eigentliche Sinn von Java sind, will ich mal etwas näher in die Geheimnisse und Faszination dieser kleinen Miniprogramme eintauchen:
Beim Starten eines Applets innerhalb einer Webseite übernimmt die browsereigene Java-VM (oder ein Java-Plugin) die weitere Arbeit. Nachdem ein Haufen von Sicherheitsprüfungen über das Applet ergangen sind, wird es schließlich von der Java-VM instanziert und initialisiert. Da Applets von der Java-VM als Objekte behandelt werden (was infolge der Syntax von Java problemlos möglich ist), können auch mehrere Applets gleichzeitig auf einer Webseite sein.
Applets, die sich auf einer gemeinsamen Webseite befinden, haben derweilen immer das Recht, untereinander zu kommunizieren und sich ggf. gegenseitig zu steuern. Somit kann man interessante Interaktionen hervorrufen und professionelle Programmangebote darbieten. Allerdings ist ein Applet immer statisch an seinen Platz gebunden. Es kann sich nicht wie diverse JavaScript-Spielereien auf dem Browserschirm hin- oder herbewegen. Genaugenommen ist der lokale Interaktionsradius eines Applets exakt auf seinen im HTML-Code definierten Platz begrenzt.
Diesen Platz nennt man in der Javawelt ganz schlicht und einfach den Sandkasten. Dort in seinem Sandkasten kann das Applet tun und lassen, was es will. Es kann erscheinen, veschwinden, Farben anzeigen, 3D-Grafik anzeigen oder die tollsten Berechnungen vollführen. Die einzigen Restriktionen sind wie gesagt die Sicherheitsvorgaben des berühmt-berüchtigten SecurityManagers der Java-VM.
Nur signierte Applets haben eine Option auf Freischaltung der gesperrten Funktionen. Und selbst nach der Freigabe bestimmt der User, ob und was das signierte dann darf oder nicht. Hintergrund war damals die Angst, daß man mit Applets (am besten noch unsichtbaren Mikroapplets) heimlich das System des Bneutzer infiltrieren, ausspionieren oder beschädigen könnte. Und in der Tat! Bis Java 1.1 war das auch möglich!
Erst als die ersten Hackerapplets Schaden angerichtet hatten, entschloß man sich zur Sperrung aller betriebssystemeigenen Funktionen für Applets. Das schadetet den Applets ein wenig in ihrem Ansehen, so daß viele professionelle Programmierer dem Applet (und somit auch Java) keine oder nur geringe Beachtung schenkten. Dagegen war die Grafik- und Demoszene heiß auf die Applets, denn man konnte dort ganz kurz und knapp demonstrieren, was man draufhatte. Daher geriet Java auch in den ersten zwei bis drei Jahren rasch in die „Freak-Ecke“. Das lag aber auch teils an JavaSoft selber, denn Bibliotheken für professionelle Programme gab es nicht, so daß man also nur „freakige“ Sachen mit Applets demonstrieren konnte.
Ein anderer Grund waren übrigens noch die sehr fehlerbehaftete Implementierung von Java 1.0 und die teilweise sehr beschissenen (sorry) Ideen, die man Java mit auf den Weg gegeben hatte. Das Event-System (also die Nachrichtenbehandlung innerhalb eines Java-Programms auf Reaktionen wie Mausbewegung, Fensteroperationen oder Tastendrücke ect.) glich sehr dem etwas evil anmutendem WinAPI Event-System, sprich es sah aus wie eine billige C-Implementierung und kam der objektorientierten Seite von Java in keinster Weise entgegen…
Trotzdem wucherten Applet-Seiten wie Unkraut im Internet! Die Fülle an mehr oder weniger brauchbaren Applets zur Dekoration oder Unterstreichung einer Webseite war unglaublich bzw. ist es immer noch. Die meisten Applets sind zwar qualitativ voll daneben, aber die Perlen der Appletkunst (siehe z.B. Anfy Applets) demonstrieren nachwievor, was man mit Java und Applets alles so machen kann.
Wer selber einmal auf den Geschmack gekommen ist, kleine Applets als Hilfsmittel zur Erklärung komplizierter Vorgänge einzusetzen, der weiß recht schnell, was für ein mächtiges Feature er da einsetzen kann. Zudem ist die Programmierung eines Applets schnell und einfach, so daß man schon innerhalb von 5 Minuten was „Tolles“ auf die Beine stellen kann…
Dieses Tutorial stammt aus der ehemaligen Sammlung des resourcecode.de und konnte dank der freundlichen Zustimmung des Autors in das thewall-Wiki übertragen werden.