Tim Ellison wrote:
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?
We are doing this to conform to some convention, right? If the
covention for jvm.dll is a standard invocation API, why would we also
bundle in the harmony-specific VMI API?
Why not keep that separate and try to push that forward as a convention
as well?
geir
