Jimmy, Jing Lv wrote:
Paulex Yang wrote:
There is some enhancement on JNI spec in JDK 1.4[1], and three
methods are related to java.nio.ByteBuffer.
* |NewDirectByteBuffer|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer>
* |GetDirectBufferAddress|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress>
* |GetDirectBufferCapacity|
<http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity>
Because these methods are actually classlib dependent and JNI
implementation must know some details of ByteBuffer implementation,
current IBM VME hasn't them implemented, and seems DRLVM doesn't
implemented thoroughly(please correct me if I made mistake here,
seems DRLVM tries to get some non-api method/field of ByteBuffer, and
if fails, it return NULL or -1 as JNI spec says). And I have no idea
how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let
me know?)
I propose to provide the implementation in NIO component, and I raise
Harmony-578 for it. The idea is: export these three methods in NIO
module as hynio.dll(.so), which is loaded by Harmony launcher, and
add these methods to VMI in some way, so that the VM vendor(i.e., JNI
implementation vendor) can add these methods to JNI function table.
Other choices I can imagine now include:
1. Add related direct buffers class to kernel class, so that the VM
vendor can implement it as well as the JNI methods. IMO this is not
good choice because buffers are actually VM independent, it's not
reasonable to let VM vendor to implement these classes.
By reading the spec, it seems RI prefer this way, take direct-buffer
as kernel class ,like class String(Though maybe it is hard to tell
"kernel" and "normal" classes in RI's implementation, they're always
together there :) ).
And in Harmony, there's an interface named "DirectBuffer"
(o.a.h.nio.internal), abstract class Buffer(java.nio) and an
implementation class "ReadWriteDirectByteBuffer" (java.nio),which
contains fields and methods for JNI methods. So an easy way may be:
take these "as" kernel classes, and get Address from
DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and
new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI
methods.
I think the kernel class means the classes which heavily depends on VM
implementation, but the buffer is another story, it is the JNI actually
depends on Classlib implementation, so instead of put buffers into
kernel, I prefer to pull the three JNI methods out of VM into classlib.
2. Provides some utility methods in o.a.h.nio, add these methods to
VMI, so that VM vendor can get inside knowledge on the direct buffers
by these utilities. This option is acceptable, but it also needs to
modify VMI, and the modification is based on some Harmony specific
contract, while my proposal above is based on public JNI spec, so
this one is not preferred.
Any ideas and comments are highly welcome.
[1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
