1.4 Der Ansatz
NEXT |
PREVIOUS |
CONTENT
- Netscape's JRI ist das Interface, das den angestrebten Zielen von Sun am nächsten kam,
weshalb es als Ausgangspunkt für das JNI genommen wurde. Dies schlägt sich auch
in den gleichen Namenskonventionen, der Nutzung von field und Method IDs und der
Verwendung von lokalen und globalen Referenzen nieder.
- Nachteil: Es konnte trotzdem keine Binärkompatibilität zum JRI erhalten werden
- Obwohl Microsoft's RNI sich nicht mehr auf einen "vorsichtigen" Carbage Collector
verlassen muß, was gegenüber dem JDK 1.0 NMI ein Vorteil ist, kann es nicht
als Basis fuer das JNI dienen, da es auch die Java Objekte wie C Strukturen adressiert.
Dies hat 2 Auswirkungen:
- RNI trifft Annahmen über das Layout von Klassen im Speicher
- "write barriers", können nicht etabliert werden, was für eine erweiterte
Garbage Collection notwendig ist.
- COM sichert vollständige Binärkompatibilität über verschiedene JVMs
hinweg, und es erzeugt nur wenig overhead, eine COM Methode aufzurufen. Trotzdem kann es
aus den folgenden Gründen kein standard native interface sein:
- Es fehlt eine bestimmte Funktionalität, wie z.B. der Zugriff auf private Felder
und das Erzeugen von allgemeinen Exceptions.
- Für den Zugriff auf public Methode und Felder werden die COM Interfaces IUnknown
und IDispatch zur Verfügung gestellt, doch leider unterstützt IDispatch
keine überladenen Funktionen und case sensitivity. Desweiteren werden alle Java
Methoden, die durch IDispatch zur Verfügung gestellt werden, umschlossen
(wrapped), um dynamische Typprüfung durchführen zu können.
- COM wurde entwickelt, um komplette Softwarekomponenten (auch vollwertige Applikationen)
zusammen arbeiten zu lassen. Es ist nicht angebracht, Java Klassen oder low level
native Methoden als Softwarekomponenten zu behandeln.
- keine UNIX Unterstuetzung
- Java Klassen sind binärkompatibel zu COM Klassen. Es werden die gleichen
Sprungtabellen und Aufrufkonventionen verwandt
© 1999 Lars Jordan,
Chemnitz Java User Group