NIO Buffer questions.

[Ariel Weisberg]

Hi,

I'll only address #2.
See [1]http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase
/hbase/0.92.1/org/apache/hadoop/hbase/util/DirectMemoryUtils.java
You can manage the lifecycle of the buffers yourself even though it is
not what was intended. You don't need to manage the lifecycle since GC
should free the DBB for you.

Ariel

On Tue, Aug 21, 2012, at 09:25 AM, Salter, Thomas A wrote:

I’ve been exploring java.nio.Buffer and have some questions about why
things were done the way they were.


1.      I have an application where I thought it would be appropriate
to implement my own Buffer class, basically to deal with a series of
48-bit things.  Unfortunately ByteBuffer is not extendable for fairly
obvious reasons given its implementation, but java.nio.Buffer is also
not extendable – it’s public, but its constructor is package-private
instead of protected. In order to implement a buffer-like class I need
to duplicate all the position-related functions rather than inherit
them.  Is there a reason for this?

2.      The JNI function, NewDirectByteBuffer, lets native code
allocate a direct buffer and pass it to Java code, but there doesn’t
seem to be any way to manage the lifetime of the buffer.  This would
seem to mean NewDirectByteBuffer can only be used in tightly controlled
situations  by private Java code that closely cooperates with the
native code.  There’s no way for the native code to know when the
ByteBuffer it allocates is released by Java.  Am I missing something?

3.      The implementation of java.nio.file in sun.nio.fs uses native
buffers not just for large I/O buffers but also for passing file names
from Java to native code.  It seems to be trading off copying strings
in Java code vs. making JNI calls from native code.  What’s the
rationales behind this?




Tom Salter  |  Software Engineer  |  Java & Middleware Development

Unisys  |  2476 Swedesford Road  |  Malvern, PA  19355   |
610-648-2568 |  N385-2568

                                     cid:image002.gif at 01CBD419.9CAC0060

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended
recipient. If you received this in error, please contact the sender and
delete the e-mail and its attachments from all computers.



  Email had 1 attachment:
  * image001.gif
      3k (image/gif)

References

1. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hbase/hbase/0.92.1/org/apache/hadoop/hbase/util/DirectMemoryUtils.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/a5bb8b8e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2511 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/a5bb8b8e/image001-0001.gif