JDK-6220093 : Definition of _jobject, _jfieldID, _jmethodID in jni.h causes .NET TypeLoadException on Windows
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows
  • CPU: generic
  • Submitted: 2005-01-21
  • Updated: 2010-10-07
  • Resolved: 2005-02-09
Related Reports
Relates :  
Description
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

Comments
WORK AROUND 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. ###@###.### 2005-1-21 15:20:17 GMT ###@###.### 2005-04-13 14:32:46 GMT
2005-01-21

EVALUATION Too risky to fix. This situation needs to be release noted for Mustang and update releases. ###@###.### 2005-2-09 15:32:35 GMT
2005-01-21