Geir Magnusson Jr. wrote: > Tim Ellison wrote: >> Now I've written all that, I it's clear that we should roll the VMI >> functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll >> would export both sets of functions, i.e. >> JNI_CreateJavaVM >> JNI_GetCreatedJavaVMs >> JNI_GetDefaultJavaVMInitArgs >> VMI_GetVMIFromJNIEnv >> VMI_GetVMIFromJavaVM >> >> What do you thing? > > Why? What's wrong with both? Seems clearer to separate, and prevents > charges of "vendor lock in" :)
You'll have to explain that comment to me. Today, to use the VM a program has to load a particular implementation of harmonyvm.dll, and our classlib code links against vmi.lib and uses a particular vmi.dll. I'm proposing that to use the VM any program can link against jvm.lib but has to load a particular implementation of jvm.dll; and our classlib code also links against jvm.lib and uses the same jvm.dll. How is the second scenario harmony-specific and not the first? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
