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 equivalent jvm.dll so the proposal is that we do the same for Harmony's convention because... ...we currently don't provide a harmonyvm.lib to link against in our jdk/lib directory, and apps that embed the VM would expect to have that. The idea would be to create a stub (like we do for the vmi.lib) and leave the concrete code in the vm-specific subdirs. Again, calling this jvm.lib means we look and feel just like the RI which helps users. If users really want to hard link against a particular VM-impl then we can provide non-stub jvm.lib's in the vm-specific subdirectories (again like the vmi.lib). 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? > Are we going to have one more VM-specific lib in the common dir? Do you mean threadlib? It's destined to become common code. Regards, Tim > 2006/11/16, Tim Ellison <[EMAIL PROTECTED]>: >> 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 >> > Issue Type: Improvement >> > Components: Classlib >> > Reporter: Oliver Deakin >> > Priority: Minor >> > >> > >> > It is standard practise when writing a VM launcher to link against >> > invocation API providing libraries called jvm.dll/libjvm.so. The RI and >> > J9 VMs both follow the convention of placing a jvm.lib file (on >> Windows) >> > into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate >> > place under jre/bin. Harmony differs from this convention in two ways: >> > >> > 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This >> > means that any Windows user writing a custom launcher will not be able >> > to make calls to our invocation API. It makes sense in this case to >> > create a stubbed set of invocation API natives to build a jvm.lib in >> the >> > appropriate place. We currently do something similar to create a >> stubbed >> > vmi.lib for linking against. >> > >> > 2) The libraries providing the invocation API are currently called >> > harmonyvm.dll/libharmonyvm.so. I would suggest that these are >> renamed to >> > jvm.dll/libjvm.so to follow the conventional naming scheme. >> >> >> This seems like an eminently reasonable suggestion. >> Anyone object? If not I'll hack the jvm.lib and make the launcher look >> for both names to allow for a transition. >> >> Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
