Es ergbt fuer mich teilweise Sinn. Vor allem der Kernel-Coder haben teilweise um die GCC-Fehler "herumgebaut" und eine Änderung in GCC 3.0 wurde unter Umständen dazu führen, dass der Kernel nicht mehr stabil läuft. In der Regel sind es auch nur kleine Fehler, die nicht sonderlich ins Gewicht fallen. Die "Bereinigung" dieser würde aber schlimme Folgen in vielen Apps haben. Ich weis, "sauber programmieren". ;-)
warum macht man niecht einfach einen zwischen schrit beim compilieren wie bei c# von ms. Den könte man die platformunabhänigeit in die zweite kompiladion undterbringen -> man müste auch keinen sourscode ofenlegen
Wenn ich das ganze richtig interpretiere, ist mit Dynamic Translation so etwas wie Code-Morphing gemeint. Dazu faellt mir ein Projekt von HP fuer PA-Risc ein, in dem die einen PA-RiscPA-Risc zwischen Compilations-Layer eingesetzt haben, und damit Performancegewinne bis zu 30 % erreichen konnten. Desweiteren kommt mir da noch dieses Programm in den sinn mit dem man auf Alpha-NT maschinen x86 Winblows Programme laufen lassen konnte...
Die Reihenfolge der Events die in Swing auftreten ist z.B. plattformabhängig und die Implementierung der Threads ebenfalls, insbesondere bezueglich der Synchronisierung.
Das letztere ist zwar in der Java Language Reference festgelegt aber nicht jeder haelt sich streng daran. Deshalb sind Anwendungen auch sehr JVM abhängig. Und jede dumme Kommerzielle Anwendung bringt nun um auf Nummer sicher zu gehen eine eigene Java Runtime mit. Super meine Festplatte mag das ganz und gar nicht !!!
Aber portabel ist Java schon, der Aufwand ist sehr gering. Nur mit einem einfachen neucompilieren oder gar auslieferung einer JAR Datei ist es leider oft nicht getan, ein oder zwei Klassen muessen meistens schon noch angepasst werden.
Ein Programm, dass bereits geschriebene, und compilierte Programme laufen lässt (also ein Emulator) für jedes Betriebssystem auf jeder Plattform, sollte also jedes Betriebssystem und jede Plattform emulieren, denn sonst kann es ja nicht gehen, d.h. alleine im Falle von Windows alleine schon die gesamten Hardware aufrufe, die Benutzeroberfläche, die gesamten Programmschnittstellen ... und dass für alle Betriebssysteme??? abgesehen, dass dieses Programm wohl die gesamte Performance der CPU alleine dafür aufbrauchen würde, um zu überprüfen, welches Programm welche Funktion in welchem Betriebssystem aufruft verbrauchen würde, wird das erste Problem alleine darin bestehen, die gesamten Dokumentationen der gesamten Funktionsaufrüfe aller Betriebssysteme zu bekommen. und 'unserem Emulator' zu sagen dieses Programm läuft auf dem Betriebssystem, ist dann doch wohl etwas witzlos, denn dann kann man auch für jedes Betriebssystem einen eigenen Emulator haben. ;-) oder eben VMWare / Plex86 mit dem man dann die Betriebssysteme nebeneinander laufenlassen kann.
Java hat den Vorteil Plattformunabhängig zu sein? schön. aber Du brauchst dafür dann eben ein Programm, dass in Java geschrieben wurde. Dann lasst uns doch alle in Java Programmieren. Mmmh moment mal, wofür brauche ich denn dann die verschiedenen Plattformen??? dann lass uns doch Java OS nehmen... warum können wir dann nicht irgendein anderes Betriebssystem nehmen? z.B. Linux oder Windows oder OS/2??? Aber dann können doch die bereits vorhandenen Programme nicht mehr laufen. hmmm... dann schreiben wir eben einen Emulator, dann läufts wieder... Äääh momentmal, sind wir da nicht gerade??? Klar. auf Plex86 werden nur x86 Betriebssysteme laufen. zumindest erstmal. vielleicht kommen ja dann doch noch irgendwann andere Zeiten. wenn Transmeta mit Ihrem Prozessor andere Prozessoren emulieren kann, warum soll das dann nicht auch mal direkt unter Software gehen können???
Die plattformunabhängigkeit von Java verlagert nur das Problem der plattfromabhängigkeit von einer kapselnden Bibliothek in eine Runtime. Ich kann hier keinen großen Unterschied erkennen.
Für das Verteilen von Binaries ist es kein Vorteil, da die Binaries ja schon für eine Plattform kompiliert wurden und damit nicht mehr portabel sind.
Für das Verteilen von Sourcecode halte ich den Vorteil nur sehr gering, da mit einem einfachen ./configure - make - make install ich unter Linux auf _jeder_ Plattform zurecht komme (soweit die plattformabhängigkeit schon gekapselt wurde).
Es ist hier also nur in bestimmten Fällen ein Vorteil: 1. Internet-Applikationen z.B. Homebanking. Da ist es aber nicht weit her (versuch das mal unter anderen OS's als MS). 2. Serverapplikationen: Da sehe ich aber vor allem nur die Eleganz von Java als Vorteil (so viele verschiedene Plattformen gibt es hier nicht). 3. B2B: Hier kann ich mir einen Einsatz gut vorstellen - das nenne ich dann aber Nische.
Für daheim oder auf der Workstation? pöhhh, da sehe ich ein Linux auf jeder möglichen Hardware als wirklich seelig machende Alternative.
Plex86 kann hier eine Alternative darstellen aber es würde das Problem der Plattformabhängigkeit nicht lösen sondern nur kaschieren. Plex86 bzw. Bochs kann nur ein Notanker sein.
Daher: Linux rulez! (von mir aus auch jedes andere OS wo ./configure - make - make install funktioniert).
Zum Thema und Java und Platform unabhängig das ist die größte lüge die man der Menschheit je aufgetischt hat! Hab ihr mal größere Javaprojekte gesehen? Wenn es auf Plattformen wie Mac oder so geht wird es schwierig du siehst überall schon Plattform abhängigen Java Code ala C/C++ (ifdef) dort ist es nur über ander Mechanismen realisiert! Also Java hat sein Ziel verfehlt! Zuedm unstützen Browser wie z.B. der MSIE 4.0/5.0 oder 6.0 immer noch nur Java 1.1.8 und damit kannst du Swing und das Collection Framework in Applets auch vergessen.
Die VM von Kaffe laeuft im 16-bit Modus. Wiso weiss ich auch nicht. Einfach mal testen. Das erkennst Du dadran wie gross Integer- und Fload-Zahlen sind und ab der wievielten Stelle die Ungenauigkeit beim Rechnen beginnt. Kaffe kann halt nicht mit der Genauigkeit von Java mithalten. Da jedoch Java selber eine Virtuelle Maschine ist, die bei einem Programm auf jeder Plattform das gleiche Ergebnis liefert (wenn z.B. Rundungsfehler auftreten und das Ergebnis falsch ist, dann ist es bei allen Java-Varianten auf jeder Plattform halt das gleiche falsche Ergebnis), folgt dadraus, dass Kaffe hierbei halt einen eigenen Weg geht. Denn dort sieht das Ergebnis halt anders aus.
Teste einfach Kaffe und vergleiche es mit Java, dann wirst Du sehen was ich meine. Zu Testzwechen kannst Du auch die Beispielprogramme von www.javabuch.de nehmen. Dann stellt Du fest, wie viele Java-Programme Kaffe falsch oder garnicht ausfuehrt.
Wembler, ich verstehe nicht ganz... wie laesst Du Programm unter Linux im "16bit Modus" laufen? Oder meinst Du, dass man fuer diese JVM beim booten mem=640k angeben musst?
Beim Kommentar der an MichaelB ging, ist mir ein kleiner Fehler unterlaufen. Statt "Microsoft" muesste an einer Stelle "Sun" stehen. Richtig heisst es:
Das ist auch der Grund weshalb Sun bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen.
Zuerst einmal Hi und Hallo an alle, die mir geantwortet haben.
@ Anonymous:
Die anderen "JVMs" kenne ich alle, ja. Kaffe ist jedoch nicht einmal Java 1.1 kompatibel. Ausserdem laeuft es im 16-bit Modus und hat so seine "kleinen" inkompatiblitaeten zu Java. Die meisten Java 1.1 Programme laufen auf jeden Falls nicht auf Kaffe. Und seit Transvirtual PocketLinux erstellt hat, gibt es nun auch ein Programm, das auf Kaffe laeuft - jedoch nicht auf Java. Mir waere es hierbei lieber, wenn sich Kaffe ganz von Java trennen und etwas eigenes beginnen wuerde. Desweiteren ist Kaffe primaer fuer Embedded Systems entwickelt worden. Daher ist fuer Kaffe auch kein Swing und aehnliches geplant. Und obwohl es fuer Embedded Systems geschaffen wurde ist es erheblich langsamer als Suns J2SE.
Zu dem was Du zu Python sagst: Phython ist zwar frei und vielleicht auch eine tolle Sprache, jedoch ist es eine Scriptsprache. Daraus folgt auch, dass groessere Firmen niemals Programme wie den JBuilder dafuer erstellen werden. JBuilder ist bekanntlich selber in Java geschreiben. Wuerde man also soetwas fuer Python in Python schreiben, dann waere der Quellcode der IDE offen. Und das wollen kommerzielle Firmen nun einmal nicht. Ein weiterer Punkt ist, dass Python - weil es eine Skriptsprache ist - langsamer ist als Java. Zwar zieht Swing die Geschwindigkeit der JavaAnwendungen erheblich nach unten, doch wenn man AWT-Programme mit grafischen Python-Programmen vergleicht, oder Text-basierte Python-Programme mit Text-basierten Java-Programmen, so sind die Java-Programme schneller. Das liegt dadran, da bei Java die Programme in einen Binaercode kompiliert werden, der dem realen Maschienencode sehr aehnlich ist. Dadurch faellt beim Interpretieren/JustInTimeCompilieren nicht so viel Arbeit an, wie beim Interpretieren/JustInTimeCompilieren von Python-Programmen.
@ lucifer:
Ruby ist auch eine Skriptsprache, deshalb existieren dort die gleichen Nachteile wie bei Python, die ich Anonymous schon erwaehnt hatte.
Und bei ANSI-C/C++ ist der Quellcode plattformunabhaengig. Doch nicht zu jedem Programm hast Du den Quellcode. Und nicht jede Firma, die ein Programm erstellt, wird es auf jedem x-beliebigen Rechner kompilieren.
Ich moechte hier nur noch mal an die Telefonauskunfts-CDROM der Telekom erinnern. Das Programm wurde fuer Wintel, MacOS und Linux/Intel geschrieben. Sollte irgendjemand Linux auf einem Alpha oder einer Sparc am laufen haben, dann kann er damit nicht anfangen. :-( Und wollen wir etwa ewig bei IA32 bleiben? Irgendwann moechte ich die Hardware auch mal durch etwas Intel-inkompatibles austauschen. Linux wird dann drauf laufen. Und was ist mit den anderen Programmen? Selbst plex86 wird dann wohl nicht drauf laufen, da es gerade dadrauf optimiert wird, dass es auf Intel-Rechnern laeuft um Betriebsyteme die auf Intel-Rechner laufen dadrauf auszufuehren.
@ Freezer:
Kaffe steht unter der GPL. Einfach unter www.kaffe.org nachsehen. Ausserdem steht es auch im Quelklcode von Kaffe, dass es unter der GPL steht.
Dass hinter Kaffe eine Firma steht, finde ich jedoch nicht so problematisch. Immerhin steht Kaffe ja unter der GPL. Ausserdem hat Transvirtual auch nicht mehr so viel Einfluss auf die Lizenz von Kaffe, wie Sun es mit Java hat. Sun hat noch immer die alleinigen Rechte an Java und kann bestimmen, wie die Lizenz der Nachfolgerversion aussieht. An Kaffe haben inzwischen jedoch schon soviele nicht-TransVirtualer GPL-Code beigesteuert, dass nun Transvirtual ebensowenig etwas an der Lizenz von Kaffe tun kann, wie Linus Torvals etwas an der Lizenz von Linux veraendern kann.
@ Spark:
Die Nachteile von Pythyon habe ich weiter oben erwaehnt. Und wiso ist "fuer speziellere Anforderungen" die "Plattformunabhaengigkeit dann eh nicht mehr so wichtig" ? Ich denke, dass auch groessere Projekte plattformunabhaengig sein sollten.
Und wenn Du meinen solltest, dass fuer Hardwarenahe Programme die Plattformunabhaengigkeit nicht so wichtig sein, dann gucke Dir mal an, wie es heutzutage unter Java realisiert wird: Wenn man dort auf den Prozessor zugreifen muss, dann werden kleine Module in C/C++ mit einem Teil Assembler geschrieben, die hinterher mittels der JNI-Schnittstelle in das Java-Programm integriert werden. Wie das geht kannst Du hier nachlesen: http:// www.haertfelder.com/ JNIintro.html
@ MichaelB:
1. Es gibt keine "vernuenftigen" Java-Implementierungen. Die meisten Programme laufen doch heute auf Java2 und die freien JVMs haben noch immer Probleme mit Java 1.1. 2. Ich bemaengel nicht, dass die Koordination in der Hand von Sun liegt, sondern ich bemaengel deren Monopolstellung. Provokativ ausgedrueckt koennte ich auch sagen: "Es ist doch garnicht so schlecht, dass Windows in der alleinigen Hand von Microsoft liegt. Ist doch besser als Linux, das allen gehoert". Unegfaehr so hoert sich Dein Kommentar an. 3. Es ist nicht so wie bei Linux, wo man mal eben den Quellcode veraendern kann und es verschiedende Varianten gibt. Wenn Du Veraenderungen vornimmst und diese veroeffentlichen willst, dann musst Du Dir erst eine Genemigung von Sun holen. Quellcode vom Java nehmen und in ein vollkommen anderes Programm integrieren, dass nichts mit Java zu tun hat ist somit nicht erlaubt. Hingegen darfst Du den Java-Quellcode erweitern. Diese Erweiterungen werden hierbei automatisch Eigentum von Sun Microssytems. Das ist auch der Grund weshalb Microsoft bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen. Um diesen rechtlichen Punkt jedoch zu verschleiern hat Sun bewusst nur Teile vom Blackdown-Java verwendet. Deshalb ist auch heute noch das Sun-Java fuer Linux schlechter als das Blackdown-Java.
@ Philipp:
Sicher, Linux laeuft prinzipiell auf jeder Hardware. Jedoch muessen alle Programme die in C/C++ geschrieben sind fuer jede Hardware neu kompiliert werden. Die Nachteile hierbei habe ich weiter oben erwaehnt.
Zum Punkt mit Plex86: Ich kann verstehen, dass Du damit gerne mal ein paar Distris ausprobieren moechtest. Jedoch solltest Du hierbei nicht vergessen, dass es nur auf der "heilen Intel-Welt" geht. Sobald die Hardware-Architektur Intel-inkompatibel ist, laeuft Plex86 nicht mehr dadrauf. Oder im Fall von Bochs laeuft es erheblich langsam.
Java (oder besser die JavaVM) setzt aber im Unterschied zu Linux auf der Anwendungsebene an. Dadurch wird ein Programm vom Betriebssystem entkoppelt. Und das ist der entscheidene Unterschied. Es macht sich ganz gut, wenn man nicht wegen eines einzelnen Programms ein Betriebssystem installieren muss.
Dual-Boot reicht eben nicht. Zum einen der Aufwand (und damit Komfortverlust), wenn ich wegen einer Applikation neu booten muss und zum anderen wird damit der Datenaustausch erschwert. Mit plex86 lassen sich sogar Cut&Paste-Dinge realisieren. Sicherlich leistet ein eine solche VM gute Dienste für Testzwecke und wird dafür sicherlich auch oft verwendet, aber ich sehe ein ganz großes Potential zum einbinden von Fremdanwendungen in Linux (die sich nicht so ohne weiteres Umstellen lassen oder wo der Hersteller das auch gar nicht vorsieht) und damit steigende Akzeptanz von Linux.
Plattformunabhängigkeit hat Linux eingebaut. Linux läuft (zumindest prinzipiell) auf jeder existierenden Plattform - sofern man Plattform mit Hardware gleichsetzt. Und Java gibt es auch nicht für alle Plattformen. Die Plattformunabhängigkeit ist daher ein schwaches Argument für Java (Java macht aus anderen Gründen Sinn, z.B. wegen seines Programmierstiels).
Ich kann Plex86 (oder abstrakter eine VM) sehr gut gebrauchen, auch um nur mal ein paar Distis in einer virtuellen Umgebung austesten zu können oder um eine Beta/Alpha-Installationsumgebung zu haben).
Es ist wohl kaum das wichtigste Ziel Anwendungen laufen zu lassen. Dazu würde auch ein Dual-Boot reichen.
Kann mir einer dieses Vorgehen erklären?
----------shnip-------
More recent successes, WinNT 4.0 and QNX demo v4
Tuesday 12th of December 2000 @ 06:07 pm GMT
Recently, I booted WinNT 4.0 from a disk image
file installed under bochs some time ago, and
the QNX demo v4 boot diskette.
--------shnip-----------------
nachdem die erste phase abgeschlossen wurde, wurden "nur" Win, FreeDos und Linux getestet. Wenn ich das richtig mitbekommen hab.
con
----------shnip-------
More recent successes, WinNT 4.0 and QNX demo v4
Tuesday 12th of December 2000 @ 06:07 pm GMT
Recently, I booted WinNT 4.0 from a disk image
file installed under bochs some time ago, and
the QNX demo v4 boot diskette.
--------shnip-----------------
nachdem die erste phase abgeschlossen wurde, wurden "nur" Win, FreeDos und Linux getestet. Wenn ich das richtig mitbekommen hab.
con
Phase 1 von plex86 realisiert lediglich die Einbettung von:
-Win95(A)
-FreeDOS
-Linux 2.0.x
NT4 ist wohl noch Zukunftsmusik!
Dazu faellt mir ein Projekt von HP fuer PA-Risc ein, in dem die einen PA-RiscPA-Risc zwischen Compilations-Layer eingesetzt haben, und damit Performancegewinne bis zu 30 % erreichen konnten.
Desweiteren kommt mir da noch dieses Programm in den sinn mit dem man auf Alpha-NT maschinen x86 Winblows Programme laufen lassen konnte...
Willi
Implementierung der Threads ebenfalls, insbesondere bezueglich der Synchronisierung.
Das letztere ist zwar in der Java Language Reference festgelegt aber nicht jeder haelt
sich streng daran. Deshalb sind Anwendungen
auch sehr JVM abhängig. Und jede dumme
Kommerzielle Anwendung bringt nun um auf
Nummer sicher zu gehen eine eigene Java
Runtime mit. Super meine Festplatte mag das
ganz und gar nicht !!!
Aber portabel ist Java schon, der Aufwand
ist sehr gering. Nur mit einem einfachen
neucompilieren oder gar auslieferung einer
JAR Datei ist es leider oft nicht getan,
ein oder zwei Klassen muessen meistens schon
noch angepasst werden.
Java hat den Vorteil Plattformunabhängig zu sein? schön. aber Du brauchst dafür dann eben ein Programm, dass in Java geschrieben wurde. Dann lasst uns doch alle in Java Programmieren. Mmmh moment mal, wofür brauche ich denn dann die verschiedenen Plattformen??? dann lass uns doch Java OS nehmen... warum können wir dann nicht irgendein anderes Betriebssystem nehmen? z.B. Linux oder Windows oder OS/2??? Aber dann können doch die bereits vorhandenen Programme nicht mehr laufen. hmmm... dann schreiben wir eben einen Emulator, dann läufts wieder... Äääh momentmal, sind wir da nicht gerade???
Klar. auf Plex86 werden nur x86 Betriebssysteme laufen. zumindest erstmal. vielleicht kommen ja dann doch noch irgendwann andere Zeiten. wenn Transmeta mit Ihrem Prozessor andere Prozessoren emulieren kann, warum soll das dann nicht auch mal direkt unter Software gehen können???
Die plattformunabhängigkeit von Java verlagert nur das Problem der plattfromabhängigkeit von einer kapselnden Bibliothek in eine Runtime.
Ich kann hier keinen großen Unterschied erkennen.
Für das Verteilen von Binaries ist es kein Vorteil, da die Binaries ja schon für eine Plattform kompiliert wurden und damit nicht mehr portabel sind.
Für das Verteilen von Sourcecode halte ich den Vorteil nur sehr gering, da mit einem einfachen ./configure - make - make install ich unter Linux auf _jeder_ Plattform zurecht komme (soweit die plattformabhängigkeit schon gekapselt wurde).
Es ist hier also nur in bestimmten Fällen ein Vorteil:
1. Internet-Applikationen z.B. Homebanking. Da ist es aber nicht weit her (versuch das mal unter anderen OS's als MS).
2. Serverapplikationen: Da sehe ich aber vor allem nur die Eleganz von Java als Vorteil (so viele verschiedene Plattformen gibt es hier nicht).
3. B2B: Hier kann ich mir einen Einsatz gut vorstellen - das nenne ich dann aber Nische.
Für daheim oder auf der Workstation? pöhhh,
da sehe ich ein Linux auf jeder möglichen Hardware als wirklich seelig machende Alternative.
Plex86 kann hier eine Alternative darstellen aber es würde das Problem der Plattformabhängigkeit nicht lösen sondern nur kaschieren. Plex86 bzw. Bochs kann nur ein Notanker sein.
Daher: Linux rulez!
(von mir aus auch jedes andere OS wo ./configure - make - make install funktioniert).
Philipp
Die VM von Kaffe laeuft im 16-bit Modus. Wiso weiss ich auch nicht. Einfach mal testen.
Das erkennst Du dadran wie gross Integer- und Fload-Zahlen sind und ab der wievielten Stelle die Ungenauigkeit beim Rechnen beginnt.
Kaffe kann halt nicht mit der Genauigkeit von Java mithalten. Da jedoch Java selber eine Virtuelle Maschine ist, die bei einem Programm auf jeder Plattform das gleiche Ergebnis liefert (wenn z.B. Rundungsfehler auftreten und das Ergebnis falsch ist, dann ist es bei allen Java-Varianten auf jeder Plattform halt das gleiche falsche Ergebnis), folgt dadraus, dass Kaffe hierbei halt einen eigenen Weg geht. Denn dort sieht das Ergebnis halt anders aus.
Teste einfach Kaffe und vergleiche es mit Java, dann wirst Du sehen was ich meine. Zu Testzwechen kannst Du auch die Beispielprogramme von www.javabuch.de nehmen. Dann stellt Du fest, wie viele Java-Programme Kaffe falsch oder garnicht ausfuehrt.
python kann man auch compilen.... kein problem wegen closed source oder geschwindigkeit...
Richtig heisst es:
Das ist auch der Grund weshalb Sun bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen.
@ Anonymous:
Die anderen "JVMs" kenne ich alle, ja. Kaffe ist jedoch nicht einmal Java 1.1 kompatibel. Ausserdem laeuft es im 16-bit Modus und hat so seine "kleinen" inkompatiblitaeten zu Java. Die meisten Java 1.1 Programme laufen auf jeden Falls nicht auf Kaffe. Und seit Transvirtual PocketLinux erstellt hat, gibt es nun auch ein Programm, das auf Kaffe laeuft - jedoch nicht auf Java.
Mir waere es hierbei lieber, wenn sich Kaffe ganz von Java trennen und etwas eigenes beginnen wuerde.
Desweiteren ist Kaffe primaer fuer Embedded Systems entwickelt worden. Daher ist fuer Kaffe auch kein Swing und aehnliches geplant. Und obwohl es fuer Embedded Systems geschaffen wurde ist es erheblich langsamer als Suns J2SE.
Zu dem was Du zu Python sagst: Phython ist zwar frei und vielleicht auch eine tolle Sprache, jedoch ist es eine Scriptsprache. Daraus folgt auch, dass groessere Firmen niemals Programme wie den JBuilder dafuer erstellen werden. JBuilder ist bekanntlich selber in Java geschreiben. Wuerde man also soetwas fuer Python in Python schreiben, dann waere der Quellcode der IDE offen. Und das wollen kommerzielle Firmen nun einmal nicht.
Ein weiterer Punkt ist, dass Python - weil es eine Skriptsprache ist - langsamer ist als Java. Zwar zieht Swing die Geschwindigkeit der JavaAnwendungen erheblich nach unten, doch wenn man AWT-Programme mit grafischen Python-Programmen vergleicht, oder Text-basierte Python-Programme mit Text-basierten Java-Programmen, so sind die Java-Programme schneller. Das liegt dadran, da bei Java die Programme in einen Binaercode kompiliert werden, der dem realen Maschienencode sehr aehnlich ist. Dadurch faellt beim Interpretieren/JustInTimeCompilieren nicht so viel Arbeit an, wie beim Interpretieren/JustInTimeCompilieren von Python-Programmen.
@ lucifer:
Ruby ist auch eine Skriptsprache, deshalb existieren dort die gleichen Nachteile wie bei Python, die ich Anonymous schon erwaehnt hatte.
Und bei ANSI-C/C++ ist der Quellcode plattformunabhaengig. Doch nicht zu jedem Programm hast Du den Quellcode. Und nicht jede Firma, die ein Programm erstellt, wird es auf jedem x-beliebigen Rechner kompilieren.
Ich moechte hier nur noch mal an die Telefonauskunfts-CDROM der Telekom erinnern. Das Programm wurde fuer Wintel, MacOS und Linux/Intel geschrieben. Sollte irgendjemand Linux auf einem Alpha oder einer Sparc am laufen haben, dann kann er damit nicht anfangen. :-(
Und wollen wir etwa ewig bei IA32 bleiben? Irgendwann moechte ich die Hardware auch mal durch etwas Intel-inkompatibles austauschen. Linux wird dann drauf laufen. Und was ist mit den anderen Programmen? Selbst plex86 wird dann wohl nicht drauf laufen, da es gerade dadrauf optimiert wird, dass es auf Intel-Rechnern laeuft um Betriebsyteme die auf Intel-Rechner laufen dadrauf auszufuehren.
@ Freezer:
Kaffe steht unter der GPL. Einfach unter www.kaffe.org nachsehen. Ausserdem steht es auch im Quelklcode von Kaffe, dass es unter der GPL steht.
Dass hinter Kaffe eine Firma steht, finde ich jedoch nicht so problematisch. Immerhin steht Kaffe ja unter der GPL. Ausserdem hat Transvirtual auch nicht mehr so viel Einfluss auf die Lizenz von Kaffe, wie Sun es mit Java hat.
Sun hat noch immer die alleinigen Rechte an Java und kann bestimmen, wie die Lizenz der Nachfolgerversion aussieht. An Kaffe haben inzwischen jedoch schon soviele nicht-TransVirtualer GPL-Code beigesteuert, dass nun Transvirtual ebensowenig etwas an der Lizenz von Kaffe tun kann, wie Linus Torvals etwas an der Lizenz von Linux veraendern kann.
@ Spark:
Die Nachteile von Pythyon habe ich weiter oben erwaehnt.
Und wiso ist "fuer speziellere Anforderungen" die "Plattformunabhaengigkeit dann eh nicht mehr so wichtig" ?
Ich denke, dass auch groessere Projekte plattformunabhaengig sein sollten.
Und wenn Du meinen solltest, dass fuer Hardwarenahe Programme die Plattformunabhaengigkeit nicht so wichtig sein, dann gucke Dir mal an, wie es heutzutage unter Java realisiert wird:
Wenn man dort auf den Prozessor zugreifen muss, dann werden kleine Module in C/C++ mit einem Teil Assembler geschrieben, die hinterher mittels der JNI-Schnittstelle in das Java-Programm integriert werden.
Wie das geht kannst Du hier nachlesen:
http:// www.haertfelder.com/ JNIintro.html
@ MichaelB:
1. Es gibt keine "vernuenftigen" Java-Implementierungen. Die meisten Programme laufen doch heute auf Java2 und die freien JVMs haben noch immer Probleme mit Java 1.1.
2. Ich bemaengel nicht, dass die Koordination in der Hand von Sun liegt, sondern ich bemaengel deren Monopolstellung. Provokativ ausgedrueckt koennte ich auch sagen: "Es ist doch garnicht so schlecht, dass Windows in der alleinigen Hand von Microsoft liegt. Ist doch besser als Linux, das allen gehoert". Unegfaehr so hoert sich Dein Kommentar an.
3. Es ist nicht so wie bei Linux, wo man mal eben den Quellcode veraendern kann und es verschiedende Varianten gibt. Wenn Du Veraenderungen vornimmst und diese veroeffentlichen willst, dann musst Du Dir erst eine Genemigung von Sun holen. Quellcode vom Java nehmen und in ein vollkommen anderes Programm integrieren, dass nichts mit Java zu tun hat ist somit nicht erlaubt.
Hingegen darfst Du den Java-Quellcode erweitern. Diese Erweiterungen werden hierbei automatisch Eigentum von Sun Microssytems.
Das ist auch der Grund weshalb Microsoft bei seiner ersten Java-Version fuer Linux Code vom Blackdown-Java verwendet hatte ohne diese zu erwaehnen. Um diesen rechtlichen Punkt jedoch zu verschleiern hat Sun bewusst nur Teile vom Blackdown-Java verwendet. Deshalb ist auch heute noch das Sun-Java fuer Linux schlechter als das Blackdown-Java.
@ Philipp:
Sicher, Linux laeuft prinzipiell auf jeder Hardware. Jedoch muessen alle Programme die in C/C++ geschrieben sind fuer jede Hardware neu kompiliert werden. Die Nachteile hierbei habe ich weiter oben erwaehnt.
Zum Punkt mit Plex86:
Ich kann verstehen, dass Du damit gerne mal ein paar Distris ausprobieren moechtest. Jedoch solltest Du hierbei nicht vergessen, dass es nur auf der "heilen Intel-Welt" geht. Sobald die Hardware-Architektur Intel-inkompatibel ist, laeuft Plex86 nicht mehr dadrauf. Oder im Fall von Bochs laeuft es erheblich langsam.
Java (oder besser die JavaVM) setzt aber im Unterschied zu Linux auf der Anwendungsebene an.
Dadurch wird ein Programm vom Betriebssystem entkoppelt. Und das ist der entscheidene Unterschied. Es macht sich ganz gut, wenn man nicht wegen eines einzelnen Programms ein Betriebssystem installieren muss.
Dual-Boot reicht eben nicht. Zum einen der Aufwand (und damit Komfortverlust), wenn ich wegen einer Applikation neu booten muss und zum anderen wird damit der Datenaustausch erschwert. Mit plex86 lassen sich sogar Cut&Paste-Dinge realisieren.
Sicherlich leistet ein eine solche VM gute Dienste für Testzwecke und wird dafür sicherlich auch oft verwendet, aber ich sehe ein ganz großes Potential zum einbinden von Fremdanwendungen in Linux (die sich nicht so ohne weiteres Umstellen lassen oder wo der Hersteller das auch gar nicht vorsieht) und damit steigende Akzeptanz von Linux.
Gruß
Michael
Und Java gibt es auch nicht für alle Plattformen.
Die Plattformunabhängigkeit ist daher ein schwaches Argument für Java (Java macht aus anderen Gründen Sinn, z.B. wegen seines Programmierstiels).
Ich kann Plex86 (oder abstrakter eine VM) sehr gut gebrauchen, auch um nur mal ein paar Distis in einer virtuellen Umgebung austesten zu können oder um eine Beta/Alpha-Installationsumgebung zu haben).
Es ist wohl kaum das wichtigste Ziel Anwendungen laufen zu lassen. Dazu würde auch ein Dual-Boot reichen.
Philipp