harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Date Wed, 14 Jun 2006 02:57:22 GMT
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.

> 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


Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message