[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-dotnet-language-devs
Subject:    MC++ bug?
From:       Ted Neward <tneward () JAVAGEEKS ! COM>
Date:       2002-03-20 11:59:55
[Download RAW message or body]


I have some code in MC++ that wants to interoperate with a foreign
environment whose name begins with J:

#using <mscorlib.dll>
using namespace System;
#include <jni.h>

int main()
{
  JNIEnv* env;
  JavaVM* vm;

  JavaVMInitArgs vm_args;
  JavaVMOption options[2];

  int n=0;
  options[n++].optionString = "-verbose:jni";                   /* print
JNI-related messages */
  options[n++].optionString = "-verbose:class";                   /* print
JNI-related messages */

  vm_args.version = JNI_VERSION_1_2;
  vm_args.options = options;
  vm_args.nOptions = n;
  vm_args.ignoreUnrecognized = 1;

  jint res = ::JNI_CreateJavaVM(&vm, (void **)&env, &vm_args);
  jclass cls = env->FindClass("Hello");
  jmethodID m = env->GetStaticMethodID(cls, "main", "()V");
  env->CallStaticVoidMethodV(cls, m, 0);
}


I compile this with VS.NET, and execution fails because it claims that the
_jmethodID type cannot be loaded--and sure enough, I ildasm the executable,
and no _jmethodID type shows up in the assembly. jclass is there, but no
_jmethodID.

For the record, jmethodID is declared in jni.h as:

struct _jfieldID;
typedef struct _jfieldID *jfieldID;

struct _jmethodID;
typedef struct _jmethodID *jmethodID;

I try a simple sample like so, to verify if this is a bug:

#using <mscorlib.dll>

struct _jfieldID;
typedef struct _jfieldID *jfieldID;

struct _jmethodID;
typedef struct _jmethodID *jmethodID;

int main()
{
  jmethodID id = 0;
  if (id == 0)
  {
    System::Console::WriteLine(S"id is 0, all right");
  }
  System::Console::WriteLine(S"Hello");
}

and lo, and behold, again, neither jmethodID nor jfieldID show up in the
compiled assembly, yet the code runs flawlessly.

I'm *completely* confused:
(a) why don't jmethodID and jfieldID show up in the compiled assembly?
(b) why does my first example require jmethodID's type, while the second one
doesn't? Alternatively, where does the second version get that type
information if it does, in fact, need it?

Ted Neward
{.NET || Java} Course Author & Instructor, DevelopMentor
(http://www.develop.com)
http://www.javageeks.com/tneward
http://www.clrgeeks.com/tneward

[prev in list] [next in list] [prev in thread] [next in thread]