harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Date Thu, 16 Nov 2006 14:33:11 GMT
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 <t.p.ellison@gmail.com>:
>> 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 (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message