U.S. patent application number 14/270442 was filed with the patent office on 2014-09-18 for system and method for reducing the static footprint of mixed-language java.tm. classes.
This patent application is currently assigned to Core Wireless Licensing S.A.R.L.. The applicant listed for this patent is Core Wireless Licensing S.A.R.L.. Invention is credited to Cristiano DI FLORA.
Application Number | 20140282452 14/270442 |
Document ID | / |
Family ID | 39585958 |
Filed Date | 2014-09-18 |
United States Patent
Application |
20140282452 |
Kind Code |
A1 |
DI FLORA; Cristiano |
September 18, 2014 |
SYSTEM AND METHOD FOR REDUCING THE STATIC FOOTPRINT OF
MIXED-LANGUAGE JAVA.TM. CLASSES
Abstract
A system and a method for minimizing the functionality-gap
between JAVA.TM. and native platforms while keeping the impact on
each JAVA.TM. API static footprint as small as possible. A JAVA.TM.
Runtime Dynamic Invocation API is used for low-level bridging
between JAVA.TM. and C/C++, enabling the dynamic invocation of
native C/C++ functions and C++ class/object methods from the
JAVA.TM. side without adding any additional ad hoc implemented
native code to the overall JAVA.TM. component implementation.
Thereby, the need to write new native code when implementing a
JAVA.TM. component that needs to invoke some native functionality
is reduced.
Inventors: |
DI FLORA; Cristiano;
(Tampere, FI) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Core Wireless Licensing S.A.R.L. |
Luxembourg |
|
LU |
|
|
Assignee: |
Core Wireless Licensing
S.A.R.L.
Luxembourg
LU
|
Family ID: |
39585958 |
Appl. No.: |
14/270442 |
Filed: |
May 6, 2014 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11618518 |
Dec 29, 2006 |
8756616 |
|
|
14270442 |
|
|
|
|
Current U.S.
Class: |
717/153 |
Current CPC
Class: |
G06F 8/4434 20130101;
G06F 8/41 20130101; G06F 9/4484 20180201 |
Class at
Publication: |
717/153 |
International
Class: |
G06F 9/45 20060101
G06F009/45 |
Claims
1. A method comprising: providing, in an electronic device, a
runtime dynamic invocation (RDI) application program interface
(API) configured to interact with applications, native APIs, or
some combination thereof; and enabling the applications, the native
APIs, or some combination thereof to manipulate native language
entities at runtime via the RDI API using a plurality of
interfaces, without necessitating additional application-specific
native code.
2. The method of claim 1, wherein the plurality of interfaces each
include boilerplate code for manipulation of the native language
entities.
3. The method of claim 1, wherein the plurality of interfaces
include a construction interface, and wherein the construction
interface is used by the applications, the native APIs, or some
combination thereof to create basic native language entities.
4. The method of claim 1, wherein the plurality of interfaces
include a destruction interface, and wherein the destruction
interface is used by the applications, the native APIs, or some
combination thereof to destroy basic native language entities.
5. The method of claim 1, wherein the plurality of interfaces
include an invocation interface, and wherein the invocation
interface is used by the applications, the native APIs, or some
combination thereof to invoke native language methods and functions
at runtime.
6. The method of claim 1, wherein the basic native language
entities available for manipulation by the applications, the native
APIs, or some combination thereof include objects, primitive
data-type variables, structures, and function pointers.
7. The method of claim 1, wherein the manipulation of the native
language entities includes using the RDI API to at least
selectively invoke native APIs exported by a dynamic link
library.
8. The method of claim 1, wherein the manipulation of the native
language entities includes using the RDI API to at least
selectively invoke native APIs that have not been exported by a
dynamic link library.
9. The method of claim 8, wherein unexported native APIs are each
wrapped in at least one downcalling wrapper function.
10. The method of claim 9, wherein the wrapped, unexported native
APIs are included in a dynamic invocation library.
11. The method of claim 10, wherein the dynamic invocation library
includes an entry point table, wherein the entry point table is
usable by the RDI for performing the invocation of an existing
native API.
12. The method of claim 8, wherein the unexported native APIs
include template functions and inlined functions.
13. The method of claim 1, wherein a plurality of pointers are used
to dynamically represent native entities on a side of the RDI
API.
14. The method of claim 13, wherein the plurality of pointers
include at least one native object pointer, native function
pointer, native primitive data-type pointer and native structure
pointer.
15. A computer program product, embodied in a non-transitory
computer readable medium, comprising: computer code for providing a
runtime dynamic invocation (RDI) application program interface
(API) configured to interact with applications, native APIs, or
some combination thereof; and computer code for enabling the
applications, the native APIs, or some combination thereof to
manipulate native language entities at run-time via the RDI API
using a plurality of interfaces, without necessitating additional
application-specific native code.
16. The computer program product of claim 15, wherein the plurality
of interfaces each include boilerplate code for manipulation of the
native language entities.
17. The computer program product of claim 15, wherein the plurality
of interfaces include a construction interface, and wherein the
construction interface is used by the applications, the native
APIs, or some combination thereof to create basic native language
entities.
18. An apparatus, comprising: a processor; and a memory unit
communicatively connected to the processor, wherein the memory unit
comprises a runtime dynamic invocation (RDI) application program
interface (API) configured to enable applications, native APIs, or
some combination thereof to manipulate native language entities at
run-time via the RDI API using a plurality of interfaces, without
necessitating additional application-specific native code.
19. The apparatus of claim 18, wherein the plurality of interfaces
each include boilerplate code for manipulation of the native
language entities.
20. The apparatus of claim 18, wherein the plurality of interfaces
include a construction interface, and wherein the construction
interface is used by the applications, the native APIs, or some
combination thereof to create basic native language entities.
Description
[0001] This patent application is a continuation of U.S. patent
application Ser. No. 11/618,518, filed on Dec. 29, 2006. U.S.
patent application Ser. No. 11/618,518 is incorporated herein by
reference.
FIELD OF THE INVENTION
[0002] The present invention relates generally to native code
invocation from JAVA.TM. classes. More particularly, the present
invention relates to systems for reducing the size and static
footprint of "mixed language" or mixed-mode code JAVA.TM. classes,
i.e., classes having one or more methods implemented in programming
languages other then JAVA.TM..
BACKGROUND OF THE INVENTION
[0003] This section is intended to provide a background or context
to the invention that is recited in the claims. The description
herein may include concepts that could be pursued, but are not
necessarily ones that have been previously conceived or pursued.
Therefore, unless otherwise indicated herein, what is described in
this section is not prior art to the description and claims in this
application and is not admitted to be prior art by inclusion in
this section.
[0004] JAVA.TM. is an object-oriented programming language and
platform that was originally developed in the early 1990s. JAVA.TM.
components can invoke native platform application programming
interfaces (APIs) by using a standard native code embedding
mechanism, commonly referred to as a JAVA.TM. Native Interface
(JNI.TM.). The JNI.TM. is primarily intended to foster native API
reuse or to implement mission-critical parts of the code in a
native language for improved efficiency. The JNI.TM. approach is
quite helpful for the reuse of existing APIs from JAVA.TM.. The
JNI.TM. allows a component written in the JAVA.TM. language to call
code written in any other programming language by declaring one or
more native JAVA.TM. methods, implementing a native library
containing one or more functions that implement the native JAVA.TM.
methods in a different programming language, loading the library
that contains the native code, and then calling the native
method.
[0005] The static footprint of a JNI.TM.-based mixed-language
JAVA.TM. class comprises two primary contributions, namely the
JAVA.TM. class (bytecode) footprint and the additional native code
footprint. Native code comprises the method's business logic
implementation and additional JNI.TM.-specific boilerplate code
(e.g., for marshalling/un-marshalling I/O parameters between
JAVA.TM. and native side, to create new JAVA.TM. objects and/or to
invoke methods on a JAVA.TM. object from native code). Invoking
native objects from JAVA.TM. via JNI.TM. requires the addition of
more JAVA.TM.-side and native-side boilerplate code in order to
deal with a native object's lifecycle (i.e., invocation of a native
object constructors, methods, and destructors) since JNI.TM. relies
on a procedural programming model. Thus, object-oriented concepts
must be implemented from scratch on top of the functional JNI.TM.
programming model.
[0006] When using JNI.TM. to implement JAVA.TM. system components
and APIs, developers must find a satisfactory trade-off between a
pair of conflicting requirements. The first such requirement is to
provide a minimum functionality-gap, meaning that most of the
native APIs available to native developers should be available to
JAVA.TM. components as well. The second requirement is for a
minimum JAVA.TM. component static footprint. In other words, adding
new JAVA.TM. APIs to a certain JAVA.TM. runtime should not have a
strong impact on the overall JAVA.TM. runtime static footprint in
terms of both native and JAVA.TM. libraries to be added. This
requirement is very important when deploying and running JAVA.TM.
platforms on embedded and mobile devices which often possess
relatively low memory and processing capabilities.
[0007] Unfortunately, the above two requirements conflict with each
other, as minimizing the functionality-gap by using JNI.TM. can
cause the final static footprint of a JAVA.TM. component to
increase significantly. This is commonly referred to as footprint
explosion. In fact, the one-to-one relationship between native
JAVA.TM. methods and functions in the native implementation makes
the amount of native code used to implement native JAVA.TM. methods
increase when the number of JAVA.TM. native methods to implement
increases. Even if native boilerplate code can be reused by
wrapping frequently used libraries in a JAVA.TM. API, as depicted
in FIG. 1, it is still difficult to avoid footprint explosion since
the more native functions are wrapped, the larger the size of the
additional JNI.TM. code. This conflict is even more difficult to
solve when dealing with object-oriented native APIs due to the
existing programming model mismatch between the JNI.TM. C
primitives and the C++ object-oriented programming model.
[0008] A number of proposals have been made to enable JAVA.TM.
wrapping of native C++ objects. These proposals are discussed, for
example, in the Simplified Wrapper and Interface Generator (SWIG)
User's Manual 1.1, (available at the SWIG website); U.S. Pat. No.
6,066,181, issued May 23, 2000; and U.S. Patent Publication No.
2005/0044540, published Feb. 24, 2005. These documents discuss a
pair of strategies for the JAVA.TM. wrapping. However, the
processes discussed in these documents do not allow for the
minimizing of the static footprint, as they require one new native
library for each class/function to be integrated. Therefore, the
minimizing of the functionality gap with these systems can easily
lead to footprint explosion since all boilerplate code cannot be
re-used.
[0009] In addition to the above, MICROSOFT.RTM. Corporation's C#
Programmer's Reference: Platform Invoke Tutorial (available at the
MSDN: Microsoft Development website), while somewhat useful, is
strictly limited to the invocation of native procedural APIs and
not for the invocation of object-oriented APIs.
[0010] There is therefore a need for a system and method of
reducing the functionality gap between JAVA.TM. and native
platform, while at the same time providing only a minimum impact on
the static footprint of the JAVA.TM. environment.
SUMMARY OF THE INVENTION
[0011] Various embodiments of the present invention involve a
system and a method for minimizing the functionality-gap between
JAVA.TM. and native platforms while keeping the impact on each
JAVA.TM. API static footprint as small as possible. The various
embodiments provide a general purpose mechanism for low-level
bridging between JAVA.TM. and C/C++, enabling the dynamic
invocation of native C/C++ functions and C++ class/object methods
from the JAVA.TM. side without adding any additional ad hoc
implemented native code to the overall JAVA.TM. component
implementation. In this way, the need to write new native code when
implementing a JAVA.TM. component that needs to invoke some native
functionality is drastically reduced.
[0012] With the various embodiments of the present invention, the
need for writing JNI.TM. native code in JAVA.TM. component (e.g.
JSR) implementations is reduced, as is the amount of boilerplate
code that is needed for JNI.TM. invocation. In addition, these
various embodiments enable JAVA.TM. developers to write JAVA.TM.
applications that consume native APIs without writing any
additional application-specific native code. Still further, with
these embodiments, JAVA.TM. consumers can reuse all of the needed
JAVA.TM. and native boilerplate code, thus reducing the overall
size of the resulting JAVA.TM. consumer APIs. This system can also
be used to reduce start-up time and dynamic footprints, as there
are fewer native libraries to load, and libraries are only loaded
once. Still further, this system and method can also be used for
garbage collection of native C++ objects instantiated by a JAVA.TM.
application.
[0013] These and other advantages and features of the invention,
together with the organization and manner of operation thereof,
will become apparent from the following detailed description when
taken in conjunction with the accompanying drawings, wherein like
elements have like numerals throughout the several drawings
described below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] FIG. 1 is a representation showing the process by which a
conventional JNI.TM.-based invocation of C/C++ APIs from JAVA.TM.
occurs;
[0015] FIG. 2 is a representation showing how native APIs may be
invoked without the use of any additional invocation-specific
JNI.TM. code according to various embodiments of the present
invention;
[0016] FIG. 3 is a depiction of one exemplary implementation of a
JAVA.TM. Runtime Dynamic Invocation (JRDI) system constructed in
accordance with the principles of the present invention;
[0017] FIG. 4 is a perspective view of a mobile telephone that can
be used in the implementation of the present invention; and
[0018] FIG. 5 is a schematic representation of the telephone
circuitry of the mobile telephone of FIG. 4.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0019] Various embodiments of the present invention involve a
system and a method for minimizing the functionality-gap between
JAVA.TM. and native platforms while keeping the impact on each
JAVA.TM. API static footprint as small as possible. The various
embodiments provide a general purpose mechanism for low-level
bridging between JAVA.TM. and C/C++, enabling the dynamic
invocation of native C/C++ functions and C++ class/object methods
from the JAVA.TM. side without adding any additional ad hoc
implemented native code to the overall JAVA.TM. component
implementation. In this way, the need to write new native code when
implementing a JAVA.TM. component that needs to invoke some native
functionality is drastically reduced.
[0020] FIG. 2 is a representation demonstrating how native APIs may
be invoked without the use of any additional invocation-specific
JNI.TM. code according to various embodiments of the present
invention. According to the various embodiments of the present
invention, JAVA.TM. runtime is enriched by a general purpose
JAVA.TM. Runtime Dynamic Invocation (JRDI) API 200. The JRDI API
200 provides JAVA.TM. consumers (represented as a first JAVA.TM.
consumer 210 and a second JAVA.TM. consumer 215) with a pure
JAVA.TM. programming model to native APIs. The JRDI API 200 is
responsible for allowing JAVA.TM. applications to create and
destroy instances of basic native language entities (i.e. objects,
primitive data-type variables, structures, function pointers) at
run-time, as well as to invoke methods and functions at runtime.
For clarity purposes, these different primitives are depicted in
FIG. 2 as being divided into three different interfaces--a
construction interface 220, a destruction interface 230, and an
invocation interface 240. Each interface implementation includes
all of the needed boilerplate code that is required for dealing
with common JNI.TM.-based tasks related to the dynamic creation and
destruction of C/C++ variables and objects, as well as the
invocation of native functions and methods. The JRDI API 200 in
turn can interact with a plurality of object-oriented APIs 250 and
procedural APIs 260 via C/C++ calls, relaying calls from the first
and second JAVA.TM. consumers 210 and 215, respectively.
[0021] A set of JAVA.TM. peer classes, referred to herein as
JavaPointers, is used to represent dynamically allocated native
entities on the JAVA.TM. side. Different types of native entities,
such as objects and primitive variables, are represented on the
JAVA.TM. side by an instance of a dedicated JAVA.TM. class, e.g., a
NativeObjectPointer or a NativeStructurePointer instance. As a
result of programming idioms and interfaces provided by the JRDI
API, JAVA.TM. applications can use a JavaPointer as a type of
JAVA.TM. peer-pointer in order to invoke methods on dynamically
allocated native entities, or to use them as I/O arguments when
invoking another entity's functionality. In this sense, a
JavaPointer is used in the same way as a native application would
use native pointers to manage dynamically allocated variables.
[0022] Various embodiments of the present invention operate under
the assumption that the JAVA.TM. runtime comprises two points of
functionality. First, there needs to be a working mechanism for
embedding native code in JAVA.TM. components by using the standard
JNI.TM. mechanism. Second, there must also be a working mechanism
for loading native dynamic link libraries (DLLs) at run-time.
[0023] The following is a description of a first use case involving
the creation of an effective system-development JAVA.TM. platform
for memory-constrained devices. In this situation, a mobile device
manufacturer desires to include a powerful pure-JAVA.TM.
application development platform on a memory-constrained device. In
order to accomplish this goal, almost all on-device native
functionality should be exposed to JAVA.TM. via a set of JAVA.TM.
mixed language classes representing platform features and system
calls. In this case, however, standard JNI.TM. coding can easily
lead to static footprint explosion, as the number of native
functions/methods to expose can be quite large (e.g., around
10.sup.6 functions/methods to wrap on the latest releases of one
operating system). This in turn makes a pure JNI.TM.-based approach
unsuitable for memory-constrained devices. If a general purpose
native platform invocation JAVA.TM. component is available,
JAVA.TM. developers can exploit it to invoke whatever native API
are needed from JAVA.TM. without having to write and install any
additional C/C++ application-specific library. In this way, device
manufacturers can provide an effective system-development JAVA.TM.
platform that is suitable for memory constrained devices since it
has a minimum impact on the overall JAVA.TM. platform static
footprint.
[0024] The following is a description of a second use case
involving the small footprint implementation of different
time-critical methods by re-using a large native C++
object-oriented API. In this case, a JAVA.TM. developer wishes to
implement a large number of time-critical methods of a JAVA.TM.
class. It has been decided to implement them in the C++ programming
language because the developer wishes to re-use an existing library
of C++ classes. Since JNI.TM. does not provide support for
invocation of object-oriented APIs, the wrapping of the needed
class library can require the developer to write a lot of native
and JAVA.TM. boilerplate code. However, this problem can be
alleviated if the developer can invoke the native C++
object-oriented API from JAVA.TM..
[0025] FIG. 3 depicts two alternative mechanisms for implementing
various embodiments of the present invention. As shown in FIG. 3,
the JAVA.TM. JRDI API 200 provides the first and second JAVA.TM.
consumers 210 and 215 with a set of JAVA.TM. methods for dynamic
creation (via a construction or dynamic allocation interface 220),
management (via the dynamic invocation interface 240) and
destruction (via the dynamic destruction interface 230) of native
objects, functions, structures, and primitive data-type variables
at run-time. These interfaces are implemented by a set of
general-purpose JAVA.TM. wrappers for different types of native
pointers. Each JavaPointer component can be implemented by using
the JNI.TM. approach. However, developers of JAVA.TM. consumers
still do not need to write any JNI.TM. code. For example, a native
object pointer component 315 can be considered as a JAVA.TM.-side
wrapper for a generic C++ object pointer. Such a component provides
all of the needed methods to enable dynamic creation, invocation,
and destruction of native objects. This component includes all of
the needed JNI.TM. boilerplate code for creating, invoking, and
destroying arbitrary native C++ objects from JAVA.TM. at run-time.
In addition to object pointers, this implementation also allows
JAVA.TM. consumers to create and destroy C/C++ function pointers,
as well as pointers to native structures and primitive data-type
variables. This implementation also permits JAVA.TM. consumers to
use such pointers as method arguments or as values returned by
methods/functions. These types of C++ pointers are represented in
the by different JavaPointer components in FIG. 3--the native
object pointer 315, a native function pointer 320, a native
structure pointer 325, and a native primitive data-type pointer
330.
[0026] Upon the JRDI-based dynamic creation of a native entity from
JAVA.TM., a new native variable/object is allocated on the heap,
and a new JavaPointer instance is returned to JAVA.TM. applications
for further usage. The dynamic destruction interface 230 allows
JAVA.TM. applications to explicitly remove the created native
entities from the heap.
[0027] With regard to the native APIs to invoke, the available
C/C++ functions and C++ classes may have been either exported by a
DLL or not (e.g., using template and inline functions/methods as
well as inherited methods). C and C++ compilers treat these two
alternatives differently, and such differences may have an impact
on the implementation of the JRDI API 200. In particular,
DLL-exported APIs 340 can be loaded and invoked at run-time without
a DLL invoker 345 posing any API-specific build-time constraint to
the native part of the JAVA.TM. component. However, native APIs
typically also include other C/C++ definitions and declarations,
such as template methods/functions 380 and inline methods/functions
390. These definitions and declarations can pose several build-time
API-specific dependencies between the target APIs of the native
platform and the native implementation of a JAVA.TM. consumer
component. These dependencies are due to the fact that C/C++
compilers generate templates instantiations and expand inline code
only at the calling block and add them statically to the calling
component's object code at build-time.
[0028] Therefore, in addition to DLL-based invocation, an exemplary
JRDI implementation may also include components for invoking
functionality that does not have any corresponding entry points in
DLLs and thus may pose some build-time dependencies to the
mixed-language JAVA.TM. class. In this case, each native method can
be wrapped in C-style wrappers 395 (commonly referred to as C
functions) or, more generally, downcalling wrapper functions.
Downcalling wrapper functions are functions that are used to wrap a
call to a native c/c++ API in order to enable a downcall. A
downcall refers to a call from a managed (e.g. JAVA.TM.) component
to a native (e.g. C/C++) function or method. The necessary wrappers
can then be included into a dedicated library, namely a dynamic
invocation library (DIL) 350. In addition to wrappers, the DIL 350
also includes an array of opaque function pointers. These pointers
are referred to as an Entry Point Table (EPT) 360, which is used by
the entry point table invoker component 370 of the JRDI library to
perform the actual invocation of the needed existing native
API.
[0029] In various embodiments, the JRDI framework relies on the
invokers to actually invoke a given native method at run-time by
using either DLL-based or EPT-based JRDI approach. For this
purpose, in these embodiments the JRDI framework includes two
primary invoker components, namely CDynLibInvoker and CEPTInvoker
components. These components are derived from the same mixin class,
namely MJRDInvoker, which represents the abstract core of the
low-level invocation API. Each invoker instance is associated with
an instance of a given native class that has been previously
allocated on the heap during invoker's creation. Upon native object
creation, each invoker holds a pointer to it that is represented by
the iThisPointer member of the MJRDInvoker class. Such a pointer is
subsequently used to invoke different methods on the target object
instance.
[0030] The actual method-invocation approach relies on the
assumption that the member functions to invoke are represented in
native object code as calls to standard C functions. For example,
invokers assume that the following method:
int MyClass::MyMethod(int anInt) is compiled (and thus can be
invoked) as a C function having the following prototype: int
myclass_myMethod(MyClass * aThisPointer, int anInt)
[0031] It should be noted that method invocations are not
necessarily converted to such a function call from C++ compilers.
Therefore, it is assumed that the native C++ compiler supports this
calling convention. If the compiler adopts a different conventions,
the low-level JRDI API must support it explicitly. For example,
MICROSOFT.RTM. C++ Win32 and ARM RVCT compilers support different
default calling conventions and we had to deal with such a
difference when implementing the JRDI proof-of-concept
prototype.
[0032] In order to invoke a given method, invokers (both
CEPTInvoker and CDynLibInvoker) typically retrieve a generic
(function) pointer to it, and then cast it to a precise type
representing a pointer to a function having a specific prototype.
For example, in order to invoke the MyMethod method above, the
retrieved function pointer should be cast to the T1ArgMethod type
defined as follows:
TABLE-US-00001 typedef void* (*T2ArgFunction)(void *, void *)
[...............] typedef T2ArgFunction T1ArgMethod;
[0033] It is also noted that, while the first void * argument of
T1ArgMethod represents a pointer to the dynamic target-object
instance (the so-called this pointer), the second void * argument
represents the actual argument to pass to the native method, i.e.,
the int anlnt input parameter of MyClass::MyMethod. A JavaPointer
is in charge of converting arguments to void * representation, and
of invoking the appropriate method on the right invoker at
run-time. If the native method call returns any leave/error code, a
JAVA.TM. exception is thrown. For example, for invoking the
mentioned MyClass::MyMethod method, the JAVA.TM. consumer must
invoke the InvokeIntOneArg argument of the JavaPointer. This method
converts the argument to a void * and then invokes the
CallOneArgOneWayWithReturn method on the right invoker as
follows:
TABLE-US-00002 JNIEXPORT jint JNICALL
Java_com_nokia_jnai_jrdi_JavaPointer_invokeIntOneArg (JNIEnv * env,
jobject, jint aHandle, jint aOrdinal, jint aArg, jboolean aByValue)
{ TInt leaveCode = KErrNone; TInt errCode = KErrNone; TInt
returnValue; //1. Get pointer to the invoker instance and cast it
to a mixin // pointer. We don't need to know what kind of invoker
is it. MJRDInvoker* invoker =
JavaUnhand<MJRDInvoker>(aHandle); //2. Perform method
invocation if (!aByValue) {//2a. Passed by Reference: aArg address
is used as a valid // void * parameter for the invoker
TRAP(leaveCode, errCode = (TInt)invoker->
CallOneArgOneWayWithReturn(aOrdinal, &aArg)); returnValue =
aArg;} else {//2b. Passed by value: aArg value is cast to void *
type // in order for the invoker to retrieve it from the stack //
correctly TRAP(leaveCode, errCode = (TInt)
invoker->CallOneArgOneWayWithReturn (aOrdinal, (void*)aArg));
returnValue = errCode; // returns success value (KErrNone) } //3.
Throw exception if any leaveCode / errorCode have been caught
[.....................]// //4. Send return value to JavaPointer
Java-side return returnValue;
[0034] In one embodiment of the present invention, both DLL-based
and EPT-based invocation of native APIs are enabled. According to
this embodiment, in DLL-based invocation, a CDynLibInvoker
component contains an RLibrary object that is used to dynamically
load a certain target DLL containing one or more class
implementations. The CDynLibInvoker component uses the RLibrary
object at run-time to retrieve function pointers to exported
methods by ordinal (by using a RLibrary::Lookup method) in
accordance with the following code:
TABLE-US-00003 EXPORT_C void *
CDynLibInvoker::CallOneArgOneWayWithReturn(const TInt aOpOrdinal,
void *arg0){ TLibraryFunction myMethod=
libLoader->Lookup(aOpOrdinal); return
Invoke1ArgMethod(iThisPointer, (void *) myMethod, arg0, EFalse,
ETrue/*returns something*/); }
[0035] The invoked Invoke 1ArgMethod of the CDynLibInvoker object
then casts the retrieved generic (i.e., void *) function pointer to
the appropriate function prototype, and then invokes the native
method. For example, for invoking an int MyClass::MyMethod(int
anInt), the function pointer should be cast to a
TABLE-US-00004 T1ArgMethod (i.e. T2ArgFunction) pointer and then
invoked as a 2-arguments function as follows: void *
Invoke1ArgMethod ( void * thisObj, void * methodToCall, void *
arg0, const TBool isStatic, const TBool returnsSomething )
{if(returnsSomething) {T1ArgMethod
ourMethod=(T1ArgMethod)methodToCall; return ourMethod(thisObj,
arg0); } else { T1ArgMethodNoReturn
ourMethod=(T1ArgMethodNoReturn)methodToCall; ourMethod(thisObj,
arg0); } }
[0036] EPT-based invocation is similar to DLL-based invocation in
that the CEPTInvoker must retrieve the appropriate function pointer
as a void pointer, cast it to the actual function pointer type to
use, and invoke it. However, a primary difference with EPT-based
invocation involves the function-pointer retrieval mechanism. While
the CDynLibInvoker relies on the assumption that the method to
invoke is available at a given ordinal of a given DLL, the
CEPTInvoker has no DLL to refer to since the native functionality
is not exported by any existing DLL. In order to invoke unexported
native APIs, each required method/function of such APIs must be
wrapped in a C-style wrapper function having the same prototype as
the appropriate function prototype to use (e.g. T2ArgFunction). For
example, the MyClass::MyMethod method could be wrapped in a C-style
wrapper function defined as follows:
TABLE-US-00005 int JW_MyClass_MyMethod(MyClass * thisPtr, int
anInt){ return thisPtr->MyMethod(anInt); }
[0037] During the construction of a new JavaPointer, the
CEPTInvoker instance is initialized by providing it with an array
of pointers to all the required wrapper functions related to
MyClass. Such an array is defined as follows:
TABLE-US-00006 const unsigned int EPT[ ]= { (unsigned
int)JW_MyClass, //0 (unsigned int)JW_MyClass_MyMethod, //1
(unsigned int)JW_MyClass_MySecondMethod, //2 }
[0038] Given such an array, in order to invoke the mentioned
MyClass::MyMethod method, the CEPTInvoker can retrieve the pointer
to the JW_MyClass_MyMethod wrapper, and then invoke it by using the
generic CEPTInvoker::Invoke2ArgFunction method as follows:
TABLE-US-00007 EXPORT_C void *
CEPTInvoker::CallOneArgOneWayWithReturn(const TInt aOpIndex, void
*arg0){ return Invoke2ArgFunction((void *)iEPT[aOpIndex],
iThisPointer, arg0, ETrue/*returns something*/); }
[0039] It is also noted that EPT-based invocation can be used to
provide JAVA.TM.-side setter and getter methods to access a given
Class/object member variables. For example, a setter method for the
OneField member of the MyClass class could be invoked by means of
the following wrapper function:
TABLE-US-00008 void JW_MyClass_SET_OneField(MyClass * thisPtr, int
newValue){ thisPtr->OneField=newValue; }
[0040] A JavaPointer instance can hold one CEPTInvoker, as well as
multiple CDynLibInvoker instances. This approach results in forcing
each EPT to contain all of the DLL-unexported methods that the
JAVA.TM. consumer wishes to invoke on a given object, including
methods belonging exactly to object's class as well as to its
mother class(es). In other words, inherited methods are always
explicitly wrapped by a DIL, and thus explicitly represented in a
certain class' EPT.
[0041] Both the DLL-based and EPT-based approaches assume that the
JAVA.TM. developer knows beforehand the C/C++ signature of the
native functionality that his application is interested in
consuming Therefore, these approaches requires developers to
consult native service documentation, but in any case developers
must be aware of native platform's APIs if they want to use
them.
[0042] FIGS. 4 and 5 show one representative electronic device 12
within which the present invention may be implemented. It should be
understood, however, that the present invention is not intended to
be limited to one particular type of electronic device 12 or other
electronic device. The electronic device 12 of FIGS. 2 and 3
includes a housing 30, a display 32 in the form of a liquid crystal
display, a keypad 34, a microphone 36, an ear-piece 38, a battery
40, an infrared port 42, an antenna 44, a smart card 46 in the form
of a UICC according to one embodiment of the invention, a card
reader 48, radio interface circuitry 52, codec circuitry 54, a
controller 56, a memory 58 and a battery 80. Individual circuits
and elements are all of a type well known in the art, for example
in the NOKIA.TM. range of mobile telephones.
[0043] Communication devices implementing the various embodiments
of the present invention may be capable of communicating using
various transmission technologies including, but not limited to,
Code Division Multiple Access (CDMA), Global System for Mobile
Communications (GSM), Universal Mobile Telecommunications System
(UMTS), Time Division Multiple Access (TDMA), Frequency Division
Multiple Access (FDMA), Transmission Control Protocol/Internet
Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia
Messaging Service (MMS), e-mail, Instant Messaging Service (IMS),
BLUETOOTH.RTM., IEEE 802.11, etc. A communication device may
communicate using various media including, but not limited to,
radio, infrared, laser, cable connection, and the like. The
communication devices may be stationary or mobile as when carried
by an individual who is moving. The communication devices may also
be located in a mode of transportation including, but not limited
to, an automobile, a truck, a taxi, a bus, a boat, an airplane, a
bicycle, a motorcycle, etc.
[0044] The present invention is described in the general context of
method steps, which may be implemented in one embodiment by a
program product including computer-executable instructions, such as
program code, executed by computers in networked environments.
Generally, program modules include routines, programs, objects,
components, data structures, etc. that perform particular tasks or
implement particular abstract data types. Computer-executable
instructions, associated data structures, and program modules
represent examples of program code for executing steps of the
methods disclosed herein. The particular sequence of such
executable instructions or associated data structures represents
examples of corresponding acts for implementing the functions
described in such steps.
[0045] Software and web implementations of the present invention
could be accomplished with standard programming techniques with
rule based logic and other logic to accomplish the various database
searching steps, correlation steps, comparison steps and decision
steps. It should also be noted that the words "component" and
"module," as used herein and in the claims, is intended to
encompass implementations using one or more lines of software code,
and/or hardware implementations, and/or equipment for receiving
manual inputs.
[0046] The foregoing description of embodiments of the present
invention have been presented for purposes of illustration and
description. It is not intended to be exhaustive or to limit the
present invention to the precise form disclosed, and modifications
and variations are possible in light of the above teachings or may
be acquired from practice of the present invention. The embodiments
were chosen and described in order to explain the principles of the
present invention and its practical application to enable one
skilled in the art to utilize the present invention in various
embodiments and with various modifications as are suited to the
particular use contemplated.
* * * * *