Java Reference
In-Depth Information
latter case, such an MIDP component is usually divided into three main
sub-layers:
•
Java layer
•
JNI layer
•
Symbian C++ layer
This three sub-layer structure repeats itself in every JSR implementation
that uses the native Symbian OS services. Let's look more closely at each
sub-layer.
10.5.1 Java Layer
The Java layer contains the public Java APIs that are accessible to Java
applications and a substantial amount of Java implementation code. Some
of the operations are handled within the Java layer only, without going
into the native code, and return immediately to the user application code.
Other operations are required to invoke native Symbian OS services. This
usually involves using the concept of native peer objects which invoke
required native operations, on behalf of the Java object. The mapping
to native operations is never straightforward (as a matter of fact, it is
quite complex) and that requires that the Java layer does some processing
before and after delegating operations to the native peers.
To remove all doubt: although MIDP applications cannot use native
functions, system classes can do that by declaring a native function as in
Java SE. For example, the following system class defines a native function
called
_readBytes()
and passes three arguments to the native function
implementation:
package com.symbian.midp;
class MyClass
{
...
private native int _readBytes(int aNativePeerHandle, byte[] aBytes,
int aLength);
...
}
Once a native method is invoked from Java, the VM executes a
statically linked native function, in the JNI layer. For example, the above
method is mapped to a native function with the following signature:
JNIEXPORT jint JNICALL Java_com_symbian_midp_MyClass__1readBytes
(JNIEnv* aJni, jobject, jint aHandle, jbyteArray aBytes,
jint aLength)
