CRuntimeJavalike - Reflection

Topic:.ReflectionJc.ifcUserData..

Last changed: 2007-09-23

Mit den korrekten Reflection-Informationen FieldJc und dem Zeiger auf die Anwenderdaten kann auf die Attribute der Anwenderinstanz zugegriffen werden. Dabei muss die Referenz auf die Anwenderdaten auf die Adresse der ObjectJc-Basisklasse angegeben werden, wenn diese auf ObjectJc basiert. Damit ist ein static_cast<ObjectJc*>(instance) notwendig bei gegebener Instanzadresse. Die Methoden für Datenzugriffe von FieldJc übernehmen einen void-Zeiger, damit werden keinerlei Prüfungen zur Compilezeit ausgeführt. Der void-Zeiger ist aber deshalb notwendig, weil auch auf Instanzen zugegriffen werden soll, die nicht auf ObjectJc basieren. Im allgemeinen C/C++-Umfeld kann eine Vererbung von ObjectJc als wesentlichstes Paradigma nicht erzwungen werden, da mit Fremdcode auch umgegangen werden muss. Der Zwang zur fehlerfreien Programmierung ist der selbe, wie er etwa bei Operationen wie memcpy oder C-castings bzw. reinterpret_cast angewendet werden muss.

Lesen von Werten wie in Java:

int32 getInt_FieldJc(field, obj) liefert den int-Wert, gegebenfalls gecasted wenn das Element nicht vom int-Typ ist. Diese und die folgenden Methoden sind gleichartig auch in Java vorhanden.
float getFloat_FieldJc(field, obj) liefert den float-Wert, gegebenfalls gecasted.
double getDouble_FieldJc(field, obj) liefert den double-Wert, gegebenfalls gecasted.
bool getBool_FieldJc(field, obj) liefert den bool-Wert, gegebenfalls gecasted.
int64 getInt64_FieldJc(field, obj) liefert den int64-Wert, gegebenfalls gecasted.
void* get_FieldJc(field, obj, idx) liefert die Adresse einer referenzierten Instanz. Dabei wird die Adresse so korrigiert, dass eine vorhandene Basisklasse ObjectJc innerhalb der Instanz adressiert wird. In C++ ist es möglich, dass verschiedene Basisklassen innerhalb einer Instanz angeordnet werden. Für die Weiterarbeit mit Reflection muss die Referenz auf ObjectJc innerhalb einer Anwenderinstanz benutzt werden. Wenn die Anwenderinstanz nicht auf ObjectJc basiert, wird deren unmittelbare Adresse geliefert.

Die letzte Methode enthält einen Index, den es in Java nicht gibt. Ist das Datenelement kein Array, dann muss hier -1 übergegeben werden. Die Nutzung eines solchen Index sollte auch auf die anderen oben genannten Methoden erweitert werden.

Setzen von Werten wie in Java:

void getFloat_FieldJc(field, obj, float) setzt den float-Wert, gegebenfalls gecasted.
void setDouble_FieldJc(field, obj, double) setzt den double-Wert, gegebenfalls gecasted.
void setBool_FieldJc(field, obj, bool) setzt den bool-Wert, gegebenfalls gecasted.
void setInt64_FieldJc(field, obj, int64 ) setzt den int64-Wert, gegebenfalls gecasted.
void set_FieldJc(field, obj, idx) setzt die Adresse einer referenzierten Instanz. Diese Methode ist derzeit nicht implementiert, da bisher nicht benötigt.

Zugriffe für C/C++-Belange als Erweiterung

Die folgenden Methoden gibt es in dieser Art nicht in Java. Sie sind für die Datenanalyse in C/C++ notwendig:

void* getRefAddr_FieldJc(field, obj, idx) liefert die Adresse einer referenzierten Instanz. Das Verhalten ist ähnlich wie get_FieldJc(...), hier erfolgt aber keine Korrektur der Adresse auf ein ObjectJc. Die Methode wird einerseits innen benutzt, andererseits dient sie zur Anzeige des tatsächlichen Inhaltes einer Referenz ohne Korretur für Inspector-Zwecke.
void* getMemoryAddress_FieldJc(field, obj) liefert die Adresse des Feldes. Diese Methode ist innere Methode und dient zur Speicheradress- und Inhaltsanzeige (Inspector).
ClassJc const* getClassAndObj_FieldJc(field, obj, idx, void** retObj) liefert Referenz und Typ eines Fields. Diese Methode existiert nicht in Java, da in Java der Typ eines Objektes immer aus dem Object selbst ermittelt werden kann (Object.getClass). In den Reflections unter C/C++ ist das aber nicht so, da die Basisklasse Object nicht generell vorausgesetzt werden kann. Die Typinformation wird aus dem gegebenem FieldJc gelesen. Die Referenz zeigt auf die Basisklasse ObjectJc wie get_FieldJc(...) wenn vorhanden.

Verfahrensweise bei Arrays und Containern

In Java müssen Arrays und Container manuell durchsucht werden. Bei einem Array kann man immer die Länge ermitteln, unabhängig von dessen Typ. Der Elementtyp eines Arrays ist aus der Abfrage der ClassJc des Arrays ermittelbar. Dann kann ein gezielter Zugriff auf die Elemente erfolgen, wie am Beispiel des folgenden Java-Codes gezeigt wird:

 int[] testArray = new int[10]; //the users program
 //
 //inspect it:
 Object inspectObj = testArray; //type unknown...
 Class clazz = inspectObj.getClass();
 String clazzName = clazz.getName();
 if(clazzName.equals("[I"))
 { //it is an integer array:
   int[] inspectInt = (int[])inspectObj; //cast
   int length = inspectInt.length;
   inspectInt[length-1] = 333;
 }

Handelt es sich um ein Array von Referenzen auf eine Klasse, dann wird als Name "[L..." angegeben. Das L steht für Object, danach folgt die Typbezeichnung der Referenzen des Arrays. Das ist lediglich eine Zusatzinformation. Auf die Array-Elemente muss nun ähnlich dem int[]-Beispiel zugegriffen werden, wobei die Zielreferenz entweder zum angegebenen Typ passen muss oder Object ist. Von diesem Object kann dann wieder die tatsächliche getClass() ermittelt werden, eine abgeleitete Instanz ist möglich.

Handelt es sich um einen Container wie List dann muss auf den Container entsprechend zugegriffen werden, um danach die Class der Elemente zu ermitteln.

Dieses Verfahren ist umständlich aber vollständig. In C/C++ ist es deshalb nicht allgemein anwendbar, weil es in C/C++ eine größere Vielfalt von Möglichkeiten der Gestaltung von Arrays gibt. Instanzen in Arrays oder Container sind nicht immer von Object abgeleitet. Es gibt es auch den typischen Fall der embedded Arrays wie

 typedef struct MyStruct_t{ int a; float b;}MyStruct;
 MyStruct array[25];

Hierbei kann ein allgemein programmierter Zugriff nur über sizeof-Kenntnis und Adressrechnung erfolgen, weil ein casting dort nicht erfolgen kann.

Die Vielfalt der Gestaltung von Arrays und Containern wäre nur durch aufwändigere Anwenderprogrammierung als in Java zu lösen, dabei müssen die Eigenschaften der Arrays jeweils spezifisch aus den Reflection ermittelt werden. Das Verfahren ist auch nicht Java-kompatibel Daher wurde die Array/Container-Erkennung und deren Auflösung in die Grundfunktionen von FieldJc eingebaut. Ein Zusatzparameter idx sorgt für eine entsprechende Indizierung eines Elementes in einem Array oder Container. In den Reflection wird getestet, ob es sich um ein statisches Array oder um ein embedded Array fester Größe handelt. Dann ist in der jeweiligen Methode die Adressrechnung intern möglich, da die Feldgröße und Byteanzahl in den Reflection steht. Handelt es sich um ein dynamisches Array des Grundtyps ObjectArrayJc dann ist die Größe in dessen Kopfdaten ermittelbar. Auch bestimmte Typen von Containern werden berücksichtigt, wobei die Container eines UML-Frameworks mit zusätzlich zugelinkten Methoden einbezogen werden können. Die Information über den Containertyp steht in den Reflection. Die Anwenderprogrammierung ist damit wesentlich vereinfacht. Für den Fall von Object-basierenden abgeleiteten Klassen kann wie in Java von der Referenz des Array- oder Container-Elementes dessen ClassJc bestimmt werden. Das wird aber insgesamt von der oben genannten Methode getClassAndObj_FieldJc(...) ausgeführt, die von get_FieldJc() intern gerufen wird. Die Indizierung wurde derzeit noch nicht bei den set- und get-Methoden für skalare Werte ausgeführt, sollte aber als Erweiterung genauso ausgeführt werden. Damit ändern sich die Signaturen der get- und set-Methoden auf skalare Werte um diesen zusätzlichen Parameter. Ein doppelter Satz von Methoden mit oder ohne Index ist nicht empfehlenswert, da damit die Anzahl der Methoden zunimmt, andererseits mit dem idx=-1 immer eine Kompatibilität zum nichtindizierten Fall durch einfache Quellenänderung herstellbar ist.

Um solche Funktionalitäten kompatibel auch in Java abzubilden (Javalike-Konzept), ist dort eine entsprechende Klasse als Erweiterung zu java.lang.reflection.Field möglich (org.vishia.bridgeC.FieldJc) , so dass die C-Erweiterungen wieder in Java ähnlich anzutreffen sind.

6 Detaildarstellung Zugriffe auf Anwenderdaten

Topic:.ReflectionJc.accessToUserDataViaReflection.

Last changed: 2007-09-23

Bei den Datenzugriffen wird die Referenz auf die Instanz als Argument angegeben. In C ist auch bei C-like-Interfaces der Zeiger auf die Instanz immer identisch mit dem Zeiger auf die Basisklasse Object_Jc. Bei den Datenzugriffen auf Feldelemente, die selbst nicht auf Object_Jc basieren, sondern nur deren Feld-Kopfstruktur ObjectArrayHead_Jc, ist der Zeiger auf die Instanzdaten nicht auf Object_Jc* konvertierbar. Daher wird bei den Methoden des Zugriffes für C wie

 METHOD_C int getInt_Field_Jc(const Field_c* ythis, void* obj);

der Zeiger auf die Instanz in der Form void* übergeben, siehe Abschnitt "Zugriff auf Daten von Arrays ohne Reflectioninfo der einzelnen Elemente"

Bei C++ ist dagegen der Zeiger auf die Instanzdaten meist nicht identisch mit dem Zeiger auf die Basisklasse ObjectJc. Es wäre eher ein Zufall bzw. es ist nur garantiert bei einfachen Klassen, die nur auf ObjectJc basieren. Eine Referenz kann vom Typ eines Interfaces auf eine Instanz sein. In diesem Fall zeigt die Referenz auf die Daten des Interface, beginnend mit dessen virtueller Tabelle inmitten der Instanzdaten, an der das Interface angeordnet ist.

Das nachfolgende Schema zeigt ein Speicherlayout, entnommen dem TestReflection.* für die Instanz myData. Für den Aufruf per Interface kennt die aufgerufene Methode, im Bespiel accessViaInterface(MyInterface* refIfc) die Daten ab der Position refIfc. Dort steht die virtuelle Tabelle des Interfaces und danach etwaige Daten der Interfaceklasse (wenn es kein reines Interface ist). Diejenigen Methoden, die in MyData überladen sind, kennen den Offset zwischen MyData und MyInterfaceBase und korrigieren den this-Zeiger um -8. Das leistet der C++-Compiler.

 myData: 9C 99 43 00 MyData::vtbl
         DA DA 5E BA       :;baseData
 refIfc: 90 99 43 00 MyInterfaceBase::vtbl
         80 99 43 00 ObjectifcBaseJcpp::vtbl
         5E BA FC 0E                  ::significance
         0C 3E 33 00                  ::significanceAddress
 333E18: 00 00 31 02 ObjectJc::objectIdentSize
         18 3E 33 00         ::ownAddress
         CD CD FF FF         ::idSyncHandles
         C0 FA 43 00         ::reflectionClass
         70 3E 33 00 MyData::refData

Damit mit Reflection gearbeitet wird, ist die Referenz auf ObjectJc notwendig. Diese steht zwar kurz dahinter, aber die Position hängt von der Datenkonstellation insgesamt ab. Keine Zeigerarithmetik kann diese bestimmen, sondern nur der Aufruf der Methode

 ObjectJc* obj = refIfc->toObject();

die im Basis-Interface ObjectifcBaseJcpp von MyInterface definiert ist und mit

 ObjectJc* MyData::toObject(){ return this; }

implementiert ist. Dieses return this gibt nicht den original übergebenen this-Zeiger zurück, sondern addiert den Offset, um die Basisklasse ObjectJc zu referenzieren, wie es der return-Typ verlangt, ein implizites cast. Das leistet der C++-Compiler. Mit der Referenz auf die ObjectJc-Basis können nun reflection-Methoden gerufen werden:

 ClassJc const* clazz = getClass_ObjectJc(obj);
 char const* clazzName = getName_ClassJc(clazz);
 StringJc fieldName = s0_StringJc("refData");
 FieldJc const* field = getDeclaredField_ClassJc(clazz, &fieldName);
 void* refAddr = getMemoryAddress_FieldJc(field, obj);
 void* refPoor = getRefAddr_FieldJc(field, obj, -1);
 void* refObj;
 ClassJc const* clazzField =
   getClassAndObj_FieldJc(field, obj, -1, &refObj);

In diesem Beispiel wird eine Referenz auf ein Interface MyInterface ermittelt, diese Referenz zeigt im Beispiel auf eine Instanz von MyData2. Die drei Zeiger verdeutlichen das C++-typische Speicherlayout hier von der Instanz von MyData2:

 myData2:E8 99 43 00  MyData2::vtbl
         DA DA 5E BA        :;baseData
 refPoor:DC 99 43 00  MyInterfaceBase::vtbl
 333E74: CC 99 43 00  ObjectifcBaseJcpp::vtbl
         5E BA FC 0E                   ::significance
         74 3E 33 00                   ::significanceAddress
 333E80: 00 00 34 02  ObjectJc::objectIdentSize
         80 3E 33 00          ::ownAddress
         CD CD FF FF          ::idSyncHandles
         10 FB 43 00          ::reflectionClass
         56 34 12 A0  MyData2::value

MyData2 hat im Beispiel ein ähnliches Speicherlayout. Die refAddr aus den obigen Anweisungen ist diejenige, auf der die Referenz steht. Es ist der Wert0x333E28 der im oberen Speicherlayout zu finden ist. Dort steht die Referenz mit dem Wert 0x333E70, in refPoor gespeichert. Um von dieser Adresse ausgehend weiterhin mit Reflections zu arbeiten, muss man irgendwie geeignet die Adresse des ObjectJc-Anteils der Instanz zeigern. Es ist allerdings so, dass im Umfeld des C++-compilierten Codes der Typ der Referenz nicht bekannt ist. Es handelt sich um ein void*, der durch Lesen der Referenz ermittelt wird. Der Typ steht allerding in der zuständigen FieldJc-Instanz, hier field, und zwar im Typ des Fields. Dieser ist reflection_MyInterface. Für diesen Typ ist bekannt, dass er auf ObjectifcBaseJcpp basiert, entsprechend der Notation im Headerfile. In den ClassJc-Daten für reflection_MyInterface ist sowohl das entsprechende Bit in modifiers gesetzt, als auch das Datenelement posObjectBase ist gesetzt mit dem Wert 0x0004. Der Wert ergibt sich bei der Compilierung der generierten Reflection aus dem Ausdruck

 (int)(static_cast<ObjectifcBaseJcpp*>((MyInterface*)0x1000)) - 0x1000

Der Ausdruck wird vom Compiler als Konstante berechnet mit den gleichen Bedingungen, wie anderer Code compiliert wird.

Mit diesen Informationen kann nun eine Adresskorrektur des void*-Zeigers der Referenz um 4 und ein nachfolgendes cast auf den Typ ObjectIfcBaseJcpp erfolgen. Die Korrektur und cast-Aktion wird innerhalb der Routine getClassAndObj_FieldJc(...) ausgeführt:

 ObjectifcBaseJcpp* objifc = (ObjectifcBaseJcpp*)
                             ((MemUnit*)(ref) + offsetBase);

Eine Adresskorrektur und ein hartes cast ist allerdings eine Vermutung, dass alle Daten richtig sind. Wenn im Anwenderprogramm ein Fehler vorliegt, dann würde der nachfolgende Aufruf

 retObjBase = objifc->toObject();

zu einem fatalem Absturz führen, da der Maschinencode über den Speicherinhalt die virtuelle Tabelle aufsucht und dort einen indirekten Call ausführt. Im Speicher kann im Grunde genommen irgend etwas stehen, erzeugt durch gegebenenfalls einen Anwenderfehler. Ein durchaus typischer anderer Anwender-Fehler ist, dass die Compilierung der Reflection-Information möglicherweise nicht aktuell ist, da das Make-System nicht korrekt arbeitet. Daher ist vor dem Aufruf ein Sicherheitscheck eingebaut, der kaum Rechenzeit benötigt aber den letzteren Fehler entdeckt und Datenfehler mit einer höhereren Wahrscheinlichkeit entdeckt: Im ObjectIfcBaseJcpp sind zwei Datenzellen enthalten, die einerseits eine signifikante Belegung 0xefcba5e und andererseits die eigene Speicheradresse enthalten. Das ist im obigen Memory-Layout erkennbar. Bei dem Signifikanz-Wert kann man ifcbase lesen, wenn man das e als i und die 5 als s liest. Das ist im Debugmodus eine kleine Merkhilfe. Die Wahrscheinlichkeit, dass bei einem Datenfehler diese 2 Belegungen korrekt sind, aber die vtbl-Adresse falsch, ist mindestens 1 : 3.

Nach diesem Signifkanz-Check kann nun objifc->toObject() gerufen werden und damit über die korrekte Implementierung dieser Methode in der instanziierten Klasse der ObjectJc-Zeiger ermittelt werden.

Wenn eine Referenz vorliegt von einen Typ, der auf ObjectJc selbst basiert, dann ist das Verfahren adäquat. Das entsprechende Bit in den ClassJc des Referenztyps ist gesetzt, und der Offset zu ObjectJc ist bekannt, beispielsweise für den Typ MyData mit

 (int)(static_cast<ObjectJc*>((MyData*)0x1000)) - 0x1000

niedergelegt. Ein Signifikanztest ist auch hier möglich, weil in einem ObjectJc im Datenlement ownAddress immer die selbe Speicheradresse stehen soll, auf der ObjectJc liegt. Dieser Signifikanztest ist derzeit nicht aktiv, weil diese Festlegung ggf. nicht in allen Produktiv-Codes derzeit beachtet wird (TODO). Es ist allerdings auch hier nicht so kritisch, da keine Methode gerufen wird sondern im Fehlerfall lediglich ein falscher Zeiger auf ClassJc ermittelt wird. Dieser ist einerseits auch signifikanz-testbar, andererseits gibt es dann falsche Anzeigen, die von der Anwendung bemerkt werden. Der scharfe Signifikanztest sollte hier per Compileroption abschaltbar sein wo nötig und ansonsten erfolgen (TODO).

7 Methoden in Reflection

8 Zugriff auf Basisklassen und Interfaces

9 Zugriff auf Daten von Arrays ohne Reflectioninfo der einzelnen Elemente

Topic:.ReflectionJc.oldoldold.

Last changed: 2007-09-23

In Java sind alle Feldelemente, die keine einfache skalare Variable darstellen (int, float, ...), grundsätzlich über Referenzen geführt. Die referenzierten Instanzen erben von Object und sind demzufolge mit Reflections zugänglich. Beispiel:

 final class Data
 { int a;
   float f;
 }

 ...
 Data[] dataArray = new Data[12];

In dem gezeigtem Beispiel wird nicht etwa, wie in C(++) zu erwarten, ein Feld mit 12 Elementen vom Typ Data angelegt, sondern es wird nur ein Feld mit 12 nichtinitialisierten Referenzen angelegt. Würde Data nicht final sein, so könnten dort auch von Data abgeleitete Klassen referenziert werden. Um die Feldelemente tatsächlich anzulegen, ist nochmal Arbeit erforderlich:

for(int i = 0; i < dataArray.length(); i++){ dataArray[i] = new Data(); }

Erst damit bekommt man das in C erwartete Ergebnis. Java ist hier etwas komplizierter, aber dafür universell und sicher. Das entspricht dem Referenzkonzept, Java kennt keine "eingebetteten Daten", in C(++) sind eingebetteten Daten dagegen oft erwünscht und durchaus oppurtun. Ein Feld aus zusammengesetzten Elementen soll direkt angelegt werden:

 typedef struct Data_t
 { int a;
   float f;
 }Data;

 Data* dataArray = new Data[12];  //(C++)
 Data* dataArray = (Data*)(malloc(12*sizeof(Data));  //C-Variante

Dieses einfache und übliche Konstrukt aus C kennt jedoch weder eine Basisklasse Object, damit keine Reflection, noch ist eine Information über die Anzahl der Feldelemente direkt mit dem Feld verbunden vorhanden (muss geeignet extra programmiert werden).

Basisklasse ObjectArrayHead_Jc ist zu verwenden

Aus obigen Grund ist in der CRuntime_Javalike eine Basisklasse ObjectArrayHead_Jc definiert. Diese enthält die Kopfdaten eines beliebigen Feldes und ist von Object_Jc abgeleitet. Es ist möglich, dass die Feldelemente unmittelbar nach den Kopfdaten folgen.Dann bekommt man eine ähnlich kompakte Datenstruktur wie man es von C aus gewöhnt ist. Auf dieser Basis arbeitet das Reflectionprinzip für Arrays. Beispiel:

 typedef struct Data_t
 { int a;
   float f;
 }Data;


 typedef struct DataArray_t
 { ObjectArrayHead_Jc array;
   Data data[100];    //NOTE: 100 is only a debug size, use dynamic size, see sizeof_DataArray.
 }DataArray;

 /*Constructor sets default values at the elements and set the head data of array.*/
 DataArray* constructor_DataArray(DataArray* ythis, int size);

 #define sizeof_DataArray(SIZE) (sizeof(ObjectArrayHead_Jc) + SIZE * sizeof(Data))

 #define new_DataArray(SIZE) constructor_DataArray( (DataArray*)malloc(sizeof_DataArray(SIZE)), SIZE ))


 DataArray* dataArray = new_DataArray(12);

Im Speicher werden die Kopfdaten und die angegebene Anzahl von Feldelementen des Typs Data in einem Block hintereinander angeordnet. Das ist die Basis für Reflections auf Arrays.

In C: Die Reflections des Arraytypes enthalten die Informationen der Elemente In Java enthält die Reflectioninformation (Class) einer Feldinstanz lediglich den Namen des Feldes, keine weiteren Informationen. Auch das Attribut length, Bestandteil jeder Arrayinstanz, wird in den Reflections nicht angezeigt. Es ist selbstverständlich.

 final class Data
 { int a;
   float f;
 }

 ...
 Data[] dataArray = new Data[12];
 for(int i = 0; i < dataArray.length(); i++){ dataArray[i] = new Data(); }

 Class classDataArray = dataArray.getClass();
 Class classData      = dataArray[0].getClass();
 System.out.println(classDataArray.getName());
 Field[] fieldsDataArray = classDataArray.getDeclaredFields();
 System.out.println(classData.getName());
 Field[] fieldsData      = classData.getDeclaredFields();
 Field field_a           = classData.getField("a");

Die erste Ausgabe für classDataArray.getName() liefert "[Lpackage.Data" als Anzeige, das es sich um ein Feld vom Referenztyp Data handelt. Das fieldsDataArray ist ein Feld der Länge 0. Die zweite Ausgabe für classData.getName() liefert "package.Data" als Typ des Feldelementes, das fieldsData enthält die Attribute von Data.

In C(++) ist für ein mit ObjectArrayHead_Jc gebautes Feld keine Reflection für die Elemente abrufbar, statt dessen ist beides kombiniert mit

 Class_Jc* classDataArray = getClass_Object_Jc(&dataArray->array.object);
 Field_Jca* fieldsDataArray = getDeclaredFields(classDataArray);
 Field_Jc field_a           = getField_Class(classDataArray, const_String("a"));
 println_PrintStream(&System.out, getName_Class_Jc(classDataArray);

abrufbar. Die Ausgabe liefert hier wie in Java "[LData", aber fieldsDataArray enthält die Attribute des Feldelementes. Das ist möglich, da die Elemente mit genau diesem Datentyp (und im Gegensatz zu Java nicht mit einem möglicherweise abgeleitetem Datentyp oder mit null) besetzt sind.

Probleme beim Test der Gültigkeit des angegebenen Feldelementes In Java wird ein Wert eines Attributes gelesen oder gesetzt mit

 Field field_a = dataArray[0].getClass().getField("a");
 int a = field_a.getInt(dataArray[5]);
 field_a.setInt(dataArray[5], 123);

Das field_a ist dabei aus der Reflection eines Feldelementes bestimmt, aber nicht notwendigerweise aus dem des 5. Feldelementes, sondern beispielsweise aus dem ersten, da alle Elemente vom Aufbau her identisch sind. Grundsätzlich gilt in Java, dass beim Zugriff auf ein Element getestet wird, ob die angegebene Instanz dem selben Typ entspricht wie der class-Typ, der dem Field entspricht (ermittelbar auch manuell programmiert mit field_a.getDeclaringClass(). Nur so kann gesichert werden, dass keine unpassenden Instanzen beim Feldzugriff angegeben werden. Der Aufwand zur Runtime ist ähnlich kritisch/unkritisch zu bewerten wie die Tatsache in Java, dass jeder Index eines Feldes zur Runtime getestet wird. Die VM optimiert hier einiges, es handelt sich jeweils nur im Nanosekunden bei den üblichen Prozessoren.

In C(++) stehen beim adäquaten Aufruf

 Field_Jc* field_a = getField_Class_Jc(getClass_Object_Jc(dataArray),const_String_Jc("a"));
 int a = getInt_Field_Jc(field_a, dataArray[5]);
 setInt_Field_Jc(field_a, dataArray[5], 123);

die Reflection-Infos aus dataArray[i] nicht zur Verfügung, da ein Feldelement nicht auf Object basiert. Daher muss in diesem Fall der Test der Zulässigkeit des Zugriffes entfallen. Das entspricht aber dem allgemeinem Programmierparadigma in C(++). Es werden an vielen Stellen Zeiger verwendet, ohne nochmaligen expliziten Zulässigkeitstest.

Die Zulässigkeit kann per manueller Programmierung aber wie folgt getestet werden:

 if(getDeclaringClass_Field_Jc(field_a) == getClass_Object_Jc(dataArray))
 {...}

Das kann in Java ebenfalls genauso explizit erfolgen. Basis für den Test ist hier das Feld selbst, in Java steht an dieser Stelle adäquat wie oben bei der Ermittlung von field_a das Feldelement:

 if(field_a.getDeclaringClass() == dataArray[5].getClass())
 {...}

10 TODO

11 Aus Headerfiles generierte Doku

UML=/Package[ReflectionJc_h]/Namespace.ownedElement[]/Class[ClassJc]

Class ClassJc im Package ReflectionJc_h

UML=/Package[ReflectionJc_h]/Namespace.ownedElement[]/Class[ClassJc]

Attributes:

+-------'-------'-------'-------'-------'-------'-------'-------+

|                            object                             |

+-------'-------'-------'-------'-------'-------'-------'--...32+

|                             name                              |

+-------'-------'-------'-------+-------'-------'-------'-------+

|        posObjectBase          |            nSize              |

+-------'-------'-------'-------+-------'-------'-------'-------+

|          attributes           |           methods             |

+-------'-------'-------'-------+-------'-------'-------'-------+

|         superClasses          |          interfaces           |

+-------'-------'-------'-------+-------'-------'-------'-------+

|          modifiers            |             mtbl              |

+-------'-------'-------'-------'-------'-------'-------'-------

Pos. 0x0..0x = 0..NaN ( NaN bytes): object : ObjectJc
Pos. 0x..0x = NaN..NaN ( 32 bytes): name : char [32]: The typename. If it is a Class represents a primitive type, the name is such as "int", "float", "boolean".
Pos. 0x..0x = NaN..NaN ( 4 bytes): posObjectBase : int32: position of the base structure/class ObjectJc inside this type, it is the base address for the offset of fields.
Pos. 0x..0x = NaN..NaN ( 4 bytes): nSize : int32: sizeof the type. Hint: It may be longer as 64 kByte, int32 is necessary.
Pos. 0x..0x = NaN..NaN ( NaN bytes): attributes : FieldJcArray
Pos. 0x..0x = NaN..NaN ( NaN bytes): methods :
Pos. 0x..0x = NaN..NaN ( NaN bytes): superClasses :: The superclass, ObjectJc if no other superclass.
Pos. 0x..0x = NaN..NaN ( NaN bytes): interfaces :: Array of interfaces to this class.
Pos. 0x..0x = NaN..NaN ( 4 bytes): modifiers : int32: Some bits determines the kind of the Class, see Modifier_reflectJc
Pos. 0x..0x = NaN..NaN ( 5 bytes): mtbl : MtblHeadJc: Pointer to jump table for dynamic calls (virtual methods). This is a typed struct, starting with Mtbl_ObjectJc.

Methoden:

ctorM_ClassJc (rawMem) : ClassJc