harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Date Thu, 16 Nov 2006 15:38:07 GMT
2006/11/16, Tim Ellison <t.p.ellison@gmail.com>:
> 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?

if the stub is the same for each VM then +1 from me

Thanks,
Mikhail

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