Geir Magnusson Jr. wrote:
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?
No, take a look at the exports from a jvm.dll, it is the standard
invocation API + vm-specific
My thinking is that we should support the convention, but we're also
trying to create another convention with VMI.
Would the vmi.dll be usable by other implementors?
geir
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
We are doing this to conform to some convention, right? If the
covention
Geir Magnusson Jr. wrote:
My thinking is that we should support the convention, but we're also
trying to create another convention with VMI.
Would the vmi.dll be usable by other implementors?
Not really, since implementers have to hold on to our VMI function
struct from the JavaVM / JNIEnv,
ok...
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
My thinking is that we should support the convention, but we're also
trying to create another convention with VMI.
Would the vmi.dll be usable by other implementors?
Not really, since implementers have to hold on to our VMI function
struct
Oliver Deakin (JIRA) wrote:
[classlib][luni] Add creation of stub jvm.dll to luni module
Key: HARMONY-2201
URL: http://issues.apache.org/jira/browse/HARMONY-2201
Project: Harmony
Is this lib VM-specific?
Are we going to have one more VM-specific lib in the common dir?
Thanks,
Mikhail
2006/11/16, Tim Ellison [EMAIL PROTECTED]:
Oliver Deakin (JIRA) wrote:
[classlib][luni] Add creation of stub jvm.dll to luni module
Mikhail Loenko wrote:
Is this lib VM-specific?
No, er, yes, er, ... let me try to explain.
In the jre/bin/vm sub directories we have harmonyvm.dll's (which are
VM-specific), but we use the name and function export convention to code
against any compliant impl. The RI others call their
I dont' care, but as you said, have it search for both for now...
Tim Ellison wrote:
Oliver Deakin (JIRA) wrote:
[classlib][luni] Add creation of stub jvm.dll to luni module
Key: HARMONY-2201
URL:
Tim Ellison wrote:
Mikhail Loenko wrote:
Is this lib VM-specific?
No, er, yes, er, ... let me try to explain.
In the jre/bin/vm sub directories we have harmonyvm.dll's (which are
VM-specific), but we use the name and function export convention to code
against any compliant impl. The RI
2006/11/16, Tim Ellison [EMAIL PROTECTED]:
Mikhail Loenko wrote:
Is this lib VM-specific?
No, er, yes, er, ... let me try to explain.
In the jre/bin/vm sub directories we have harmonyvm.dll's (which are
VM-specific), but we use the name and function export convention to code
against any
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
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
12 matches
Mail list logo
