CLR Hosting API and Java equivalents

Attila Szegedi wrote:

    Ted, do you have an idea how do these hooks compare to the JVMTI, the new (meant to be universal) tool interface in JDK 1.5 that supersedes earlier standalone debug/profiling/etc. JVM APIs?

In truth, Attila, the CLR Hosting APIs aren’t really equivalent to JVMTI; the CLR Hosting APIs are more equivalent to the JNI Invocation API than anything else. The CLR has similar APIs to JVMTI in what they call the Profiling API and the Debugging API (sound familiar?), both of which are intended to be used from unmanaged code, as with JVMTI, but aren’t intended to bootstrap the environment into place as does JNI Invocation. So, to imagine an equivalent, picture JNI Invocation working something like this:

JavaVMInitArgs vm_args;
JavaVMOption options[4];

int n=0;
options[++n].optionString = "-Djava.class.path=.";
options[++n].optionString = "-verbose:jni";

// What follows is my flight of fancy
//
options[n].optionString = "threadMgr";
options[++n].extraInfo = new MyThreadingManager;
    // Custom class I wrote that extends ThreadManager base class
    // or something similar
options[n].optionString = "memoryMgr";
options[++n].extraInfo = new MyMemoryManager;
    // Same idea; MyMemoryManager extends MemoryManager base class
    // that does custom allocation

vm_args.version = JNI_VERSION_1_6;
    // Have to bump up version # for my new changes
vm_args.options = options;
vm_args.nOptions = n;
vm_args.ignoreUnrecognized = TRUE;

res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args);

// Assuming that res is not less than 0, we have a valid
// JNI_Env* in env, and can do the usual JNI Invocation stuff
// like look up main() on whatever the host class is, and so on
//

Now THAT would be nifty. 🙂