Native code called by Java via the JNI interface may use jobject, jmethodID, and jfieldID to refer to Java objects, methods, and object fields respectively.  These types are defined in jni.h as follows:

struct _jobject;
typedef struct _jobject *jobject;
struct _jfieldID;
typedef struct _jfieldID *jfieldID;
struct _jmethodID;
typedef struct _jmethodID *jmethodID;

So, the types are defined as pointers to opaque (undefined) structs, in order to get better compile-time type checking.  Unfortunately, if these types are used in a Windows native library compiled with Microsoft Managed Extensions for C++ (/clr compiler switch), a TypeLoadException may be thrown at runtime.  A module compiled in this way is partially managed by the .NET runtime subsystem.  In what is arguably a bug in the .NET compiler, runtime metadata is not generated for undefined structs.  When the .NET runtime encounters a pointer to an undefined struct (even if the pointer is not dereferenced), a TypeLoadException may be thrown because the runtime has no type information for the struct.

###@###.### 2005-1-21 15:20:16 GMT