+1 for common jvm.lib. I'm already asked myself looking at drlvm's vmi impl - why do we need this as separate lib, and could not find any compelling reason. On the contrary, we would need to provide extra interface vm->vmi for completing VMLS in DRLVM if we keep those libs separate.
2006/11/17, Tim Ellison <[EMAIL PROTECTED]>:
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 APIs. I suggest we do the same (though in our case it is the two additional Harmony-specific VMI functions). > Why not keep that separate and try to push that forward as a convention > as well? Why try create another convention when there is one in use in the wild? Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
