2003-02-23, 02:12
Da ich gerade eine Java Virtual Machine und begleitende Bibliotheken auf ein eingebettetes System portiere (VM in C, GUI in C++) beschäftige ich mich zwangsläufig ein wenig mit den Innereien, aber die Aussage das der Bytecode für langsame Speicherhungrige Programme sorgt ist schlichtweg falsch. Es stimmt zwar, dass bei Java ein gewisser Overhead besteht, weil ein String z.B. kein char* auf einen Speicherbereich ist und sondern ein Object und auch Arrays prinzipiell von java.lang.Object abstammen und net nur ein einfacher gemallocter Speicherbereich irgendwo (Am End ist es natürlich schon irgendwo ein gemallocter Speicher, aber da ist halt noch eine Abstraktionsebene dazwischen)
Der schlechte Ruf von Java stammt aus der Zeit, als viele Java Virtual Machines noch interpretierten. Heutzutage wird mit JIT Compilern bzw. AOT Compilern gearbeitet. Ich habe schon mit einem Java Echtzeitbetriebssystem (harte Echtzeit!) gearbeitet, das hat net schlecht funktioniert (und das geilste war, du hast von Java aus Assembler programmieren können, weil irgendwie musst jo z.B. Register setzen.)
Grundsätzlich gilt (und I zähl nur die Punkte auf, die mir sofort nach dem zweiten Pint einfallen):
Pluspunkte für Java:
+ Sichere Sprache
+ Fehler nach dem Verursacherprinzip (D.h. du kannst net irgendeinem anderen den Speicher freen und all die lustigen Fehler, wenn 30 Leute an einem einzigen System arbeiten)
+ Plattformunabhängig (wobei das IMHO net ganz richtig ist)
Minuspunkte:
- Durch die CPU <-> OS <-> VM <-> Bytecode sitzt man nicht direkt auf der CPU, was Vor und Nachteile hat. Es gibt durchaus Betriebsysteme, die nach dem Schema CPU <-> OS/VM <-> Bytecode aufgebaut sind, zusammen mit einem AOT Compiler pfeift die Sache dann schon ordentlich. Das gibts aber hautpsächlich in der Welt der Embedded System, z.B. Esmertec.
- Keine direkte Speicherzugriffe (Manipulation), wobei das net unbedingt ein Nachteil ist.
Es ist halt ein Tradeoff zwischen Geschwindigkeit bei der Ausführung/Geschwindigkeit bei der Entwicklung/Korrektheit des Programms.
Der schlechte Ruf von Java stammt aus der Zeit, als viele Java Virtual Machines noch interpretierten. Heutzutage wird mit JIT Compilern bzw. AOT Compilern gearbeitet. Ich habe schon mit einem Java Echtzeitbetriebssystem (harte Echtzeit!) gearbeitet, das hat net schlecht funktioniert (und das geilste war, du hast von Java aus Assembler programmieren können, weil irgendwie musst jo z.B. Register setzen.)
Grundsätzlich gilt (und I zähl nur die Punkte auf, die mir sofort nach dem zweiten Pint einfallen):
Pluspunkte für Java:
+ Sichere Sprache
+ Fehler nach dem Verursacherprinzip (D.h. du kannst net irgendeinem anderen den Speicher freen und all die lustigen Fehler, wenn 30 Leute an einem einzigen System arbeiten)
+ Plattformunabhängig (wobei das IMHO net ganz richtig ist)
Minuspunkte:
- Durch die CPU <-> OS <-> VM <-> Bytecode sitzt man nicht direkt auf der CPU, was Vor und Nachteile hat. Es gibt durchaus Betriebsysteme, die nach dem Schema CPU <-> OS/VM <-> Bytecode aufgebaut sind, zusammen mit einem AOT Compiler pfeift die Sache dann schon ordentlich. Das gibts aber hautpsächlich in der Welt der Embedded System, z.B. Esmertec.
- Keine direkte Speicherzugriffe (Manipulation), wobei das net unbedingt ein Nachteil ist.
Es ist halt ein Tradeoff zwischen Geschwindigkeit bei der Ausführung/Geschwindigkeit bei der Entwicklung/Korrektheit des Programms.