Native code called by Java via the JNI interface may use jobject, jmethodID, and jfieldID to refer to Java objects, methods, and  customer  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  customer  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.

  xxxxx@xxxxx   2005-1-21 15:20:16 GMT

Use

#pragma unmanaged

to mark functions using jobject, jmethodID, jfieldID as unmanaged.

The include of jni.h

#include "jni.h"

should also be in an unmanaged block.

  xxxxx@xxxxx   2005-1-21 15:20:17 GMT
  xxxxx@xxxxx   2005-04-13 14:32:46 GMT

Too risky to fix.  This situation needs to be release noted for Mustang and update releases.

  xxxxx@xxxxx   2005-2-09 15:32:35 GMT