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 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.

Yeah - I just had to work around that w/ my embedding eperiment.


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?

Why? What's wrong with both? Seems clearer to separate, and prevents charges of "vendor lock in" :)


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.


Reply via email to