harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Date Thu, 16 Nov 2006 14:55:33 GMT


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

Mime
View raw message