harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Date Thu, 16 Nov 2006 22:11:41 GMT

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?


View raw message