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.
@ 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.