Java ist... | |
---|---|
leicht | gewöhnungsbedürftig. Die Syntax ist bewußt weitgehend von C++ übernommen, und daher vielen vertraut. Viele Eigenschaften von C++ wurden aber weggelassen und anders umgesetzt. Multiple-Inheritance etwa wurde durch das Interfaces Konzept von Objective C ersetzt. Und eine Garbage-Collection sorgt dafür, daß man nicht mehr jeden Speicher selbst freigeben muß. Das vermeidet eine Menge Fehler. Die größte Einarbeitungszeit kostet jedoch der sichere Umgang mit der Objektklassen-Library und dem Multithreading. Software in Java zu entwickeln ist alles andere als leicht, es ist lediglich einfacher als C. Immerhin. |
architekturneutral | Überall da, wo der Java-Interpreter läuft, kann Java-Byte-Code ausgeführt
werden. Der Java-Byte-Code ist darauf ausgelegt, auf jedem System einfach
interpretierbar und übersetzbar zu sein - sagen die Entwickler. Zur
Zeit gilt dies für SunOS 4 und 5, SGI, DEC OSF/1, Windoofs NT und 95
sowie Linux |
einfach | zu bedienen. Software braucht nicht ausgepackt und installiert
werden. Sie kommt vielmehr per Mausclick und ist einsatzfertig.
Damals war die Einfachheit eine Applikation als Applet auf eine Webpage
integrieren zu können unglaublich. Dann aber hat Netscapes
Konkurrenztechnologie
"LiveScript" die Bedeutung von
Java im Web-Browser massiv relativiert. Sie wurde zwar bald in
"JavaScript" umbenannt, um den Eindruck zu wecken, sie stünde mit Java
nicht in Konkurrenz.
Nun ist ECMAscript, wie es inzwischen heisst, sogar die Programmiersprache
innerhalb Macromedia Flash - und Flash kann nunmal Dinge, die sich Java
immernoch erträumt.
Nur für besonders programmierintensive Anwendungen sind
Java-Applets nach wie vor die richtige Wahl, ausser man kann die Aufgaben
vom Server erledigen lassen. Dann nämlich, als Applikations- oder gar Server-Technologie ist Java alles andere als einfach, und meistens unsinnig, da Java alles in allem die langsamste Bytecode-Technologie überhaupt ist. Die anderen vergleichbaren Technologien, perl und php etwa, versuchen nicht krampfhaft einen virtuellen Microprozessor zu simulieren, sondern erlauben hochkomplexe Operationen (wie beispielsweise die Ersetzung eines Textfragments durch einem anderen innerhalb einer Datei) mit einem einzigen Bytecode (diesem: s/dieserText/jenerText/gm). Im Jahre 1995 war Java eine Revolution, nun ist es Geschichte, und ein Klotz am Bein jener, die darauf gebaut haben. |
robust | Im Gegensatz zu C++ hat Java keine Pointer-Arithmetik. Ein Objekt
ist ein Objekt und kann nicht als ein Feld von Bytes betrachtet werden
in dem man beliebig Werte verändern kann. Ein Integer kann nicht zum
Pointer »gecastet« werden. Dies macht viele C-Hacks unmöglich, reduziert
aber ebenfalls die Bug-Anfälligkeit. Unangenehm pedantisch ist die Sprache
jedoch, wenn man mit if (objekt) eigentlich
if (objekt != null) meint, und deshalb letzteres tippen muß,
weil objekt nunmal nicht boolean ist.
Diese "Robustheits"-Eigenschaft haben inzwischen sämtliche moderne Sprachen,
und alle perl-Derivatsprachen (php, python und mehr) sind alles andere als
pedantisch.
|
sicher | Java wurde für den Einsatz im Internet entwickelt, wo der Anwender seinen Rechner nicht blindlings einem unbekannten Programmierer anvertrauen möchte. Java erlaubt keine unkontrollierten Zugriffe auf Systemdateien (bei einem nicht vorgesehenem Dateizugriff wird der Benutzer gefragt) oder auf Speicherbereiche (»private« Variablen und Methoden sind wirklich privat). Auch die Kommunikation mit fremden Hosts kann beschränkt und überwacht werden. Es sollte daher recht schwer sein, ein Trojanisches Pferd in Java zu schreiben. Zusätzlich wird die korrekte Übertragung des Java-Programms in Zukunft mittels PGP, MD5 oder SSL überprüft werden. Java sollte demnach sicherer sein, als die zur Zeit gängige Praxis des Installierens von Software vom erstbesten FTP Archiv, ohne einen Blick auf den Source zu werfen, falls der überhaupt vorhanden ist. Dem "Unixler" bleibt dennoch ein mulmiges Gefühl, Programme ausführen zu lassen, dessen Source man nicht einsehen kann. Andere sind das gewohnt. Immerhin haben sich signierte Java-Applets als Online-Banking-Technologie durchgesetzt. Ja, es gibt nach wie vor Anwendungen, für die Java die richtige Wahl ist, aber in jedem Fall als Applet im Webbrowser. Update 2006: Denkste, sogar in diesem Bereich haben dynamische Web-Applikationen auf Serverseite inzwischen die Nase vorn. |
objektorientiert | Methoden mit bestimmten festgelegten Namen werden zu gegebenem
Anlaß vom System aufgerufen, etwa mouse_down() beim Mausclick.
Bestehende Klassen sind in ihrer Funktionsweise modifizierbar, in dem man sie
»erweitert« (die Sprache verwendet zur Vererbung das Keyword
extends ) und nur den entscheidenden Teil mit neuem Code
überschreibt. http://java.pages.de/classes/NewImageLoop.java ist ein kleines Beispiel
hierzu.
An der Stelle muss ich einräumen, so selbstverständlich es auch sein mag,
dass alle Sprachen heutzutage objektorientiert sind, so haben perl und
Derivate doch eine lausige Syntax dafür. Etwas angenehmer als Java ist
die flexiblere Syntax von C++ (Syntactic sugar und Preprozessor sind eben doch
nützlich). Die natürlichste Variante hat meines Erachtens
LPC, aber wer
kennt diese Bytecodesprache aus dem Jahre 1991 schon?
|
multithreaded | Java kann grundsätzlich mehrere Operationen quasi-parallel ausführen,
und bietet zur Kontrolle besondere, in der Syntax verankerte Keywords wie
synchronized . In der Praxis macht sich dies beispielsweise direkt
bei der Bedienung des Browsers HotJava bemerkbar: Man kann auf mehrere Links
klicken; diese werden dann gleichzeitig geholt und erscheinen in der
Reihenfolge der abgeschlossenen Übertragung auf dem Bildschirm. Bei der
Applet-Programmierung merkt man es auch bald: Wenn man für andauernde
Berechnungen und Animationen nicht einen eigenen Thread startet, blockiert
man schnell den Browser. Böswillige Programmierer können also leicht dem
gutmütigen Surfer den Browser lahmlegen und zum Neustart zwingen.
Aber dagegen sind Schutzmechanismen realisierbar - HotJava ist ja noch im
Alpha-Stadium.
Bald danach haben die Webbrowser gelernt mehrere Aufgaben parallel
wahrzunehmen. Im Browser ist Multithreading in der Regel gewünscht,
es gibt jedoch einige Anwendungen in denen Multithreading ein totaler
Bremsfaktor ist. Dies betrifft typischerweise Server-Anwendungen,
die mit Hunderten gleichzeitiger Client-Zugriffe klarkommen müssen.
Moderne schlaue Programmiersprachen bieten Multithreading nur auf
expliziten Wunsch des Programmierers an, also nur dann wenn man es
gebrauchen kann.
Update 2006: Java ist nur sehr spät den Bedürfnissen von Serverprogrammieren
entgegen gekommen, und hat eine Schnittstelle für thread-freie
event-orientierte Programmierung angeboten. Um den Vergleich mit LPC nochmal
zu bemühen, LPC ist seit seiner Entstehung event-orientiert.
|
schnell | Der Java-Compiler erzeugt binären Byte-Code. Der Interpreter verliert also keine Zeit mit lexikalischer Analyse und Parsing. Er kann direkt zur Tat schreiten. Wenn man den Byte-Code in den Maschinen-Code der jeweiligen Maschine zurückführt, soll er in der Geschwindigkeit kaum noch von C++ zu unterscheiden sein - laut Sun. Schneller als Interpretersprachen ist Java schon, nur gibt es letztere inzwischen kaum noch. Javascript ist langsamer als Java, aber dafür braucht man es nicht umständlich zu übersetzen (compilieren). Durch seine Einschränkung auf den simulierten Prozessor hat Java die einzigartige Fähigkeit durch just-in-time-Übersetzung (JIT) doch noch erheblich beschleunigt zu werden. Davon visionierten die Sun-Leute schon damals. Nachteil dabei, es kommt doch noch ein Übersetzungsmoment dazu. Ob das dann insgesamt schneller ist als Bytecode-Sprachen wie perl oder pike, welche von vornherein komplexe Operationen als Bytecodes anbieten, kommt sehr stark auf den Anwendungsfall an. Bei roher Mathematik kann Java punkten, bei konkreten Anwendungen stehen die reichen Bytecodesprachen meistens besser da. |
klein | Der rudimentäre Interpreter benötigt etwa 40K. Mit Standard-Library und Multithreading-Kernel kommt er auf 175K. Wir könnten eines Tages Java-Prozessor-Chips in unseren Rechnern und Fahrstühlen haben. Das wäre dann endlich mal wieder eine sinnvolle Java-Anwendung, im Ernst. Mit den neuen java-fähigen GPRS-Handies scheint diese Vision von 1995 geschlagene 7 Jahre später langsam sich zu verwirklichen. Dort ist Java tatsächlich sinnvoll eingesetzt, dafür wurde es nämlich eigentlich entwickelt, nicht für das Internet. |
verteilt | Objekte können irgendwoher aus dem Netz Objektklassen nachladen, wenn der User es ihnen erlaubt. Unsinn, so etwas hat sich überhaupt nicht etabliert. Will auch keiner. Verteilte Kommunikation ist schwer angesagt, meine Firma verdient seine Brötchen damit, aber Agententechnologien sind tot. |
erweiterbar | Der Java Compiler kennt ein Keyword native womit man Methoden
kennzeichnet, welche in einer maschinenabhängigen Sprache - etwa C -
implementiert sind. Diese Eigenschaft kann man natürlich nur in eigenständigen
Java-Programmen verwenden, nicht jedoch in WWW-Applets.
Was das alles recht sinnlos macht, dann schon lieber eine vernünftige
Applikationssprache verwenden. Sorry. Entweder man arbeitet schnell,
mit einer rapid-prototyping-Sprache wie perl, oder man entwickelt
langfristig und solide, und kehrt dafür zurück zu C++ oder gar C.
|
Weitere Details stehen im Java-White-Paper, welches beim HotJava mitgeliefert wird oder auf java.sun.com abgerufen werden kann. |