On 6/13/06, Paulex Yang <[EMAIL PROTECTED]> 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.


It seems that JCHEVM follows this way. It depends on classes from classpath
library.

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.


It seems that DRLVM follows this way, except it assumes the utility methods
are located in java.nio.ByteBuffer, not o.a.h.nio.

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]




--
Andrew Zhang
China Software Development Lab, IBM

Reply via email to