Ich bin jetzt zur hälfte durch, aber nur weil eine Bibliothek die Funktionen der VM übernimmt (und die der java bib) heisst das noch lange nicht, dass es eine VM ist. Es ist trotzdem nur eine Bibliothek.
Der Punkt ist:
eine VM (in Reinstform) interpretiert einen Maschinencode für die Maschine die sie virtuell darstellt. Dieses Konzept wird durch JIT-Compiler etwas verwässert, aber das Grundprinzip ist immer noch das gleiche - es liegt ein für die aktuelle Maschine nicht zwingend ausführbarer Code vor den die VM dann ausführt.
Ein natives Compilat hat nun andere Eigenschaften:
1. Ich kann z.B. verlinkte Bibliotheken (die auch nativ vorliegen müssen) statisch verlinken
2. Ich brauche ausser dem Binary keine weiteren Elemente mehr auf meiner Maschine.
3. Ich bin OS und Hardwareabhängig - könnte aber auch direkt Hardware ansprechen ohne die Java-Bibliotheken zu bemühen (das ginge dann allerdings nur über CodeInjection bzw. ähnlich wie bei einer Virusinfektion müsste Code zum Binary hinzugefügt werden.
4. Mein Compiler muss dafür sorgen, dass die von Java bekannten Mechanismen (z.B. GarbageCollection) entsprechend realisiert werden (z.B. durch zusätzlichen Code der mit compiliert wird oder aber durch Bibliotheken).
5. Das dynamische Nachladen von Klassen via Klassloader dürfte nicht mehr funktionieren, bzw. auf ganz anderen Mechanismen fußen z.B. Speicher allozieren, assemblierte Klasse laden, Zusatzinformationen für die Einsprungpunkte laden, Speicher ausführbar markieren, Einsprungpunkte in die entsprechenden Variablen bzw. Tabellen eintragen, ausführen).
Dies sind meiner Meinung nach gravierende Unterschiede zur VM. Es werden nur die Funktionen von der VM die für das funktionieren von Java nötig sind - nicht aber der Teil bei dem der Bytecode interpretiert/jit-compiled wird. Damit ist das native compilat keine VM.
Ich warte schon sehnsüchtig auf die Gegenargumente
