NIO Buffer questions.

[Alan Bateman]

On 21/08/2012 14:25, 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?
>
This is by design, buffers are not an extensible abstraction. Is the 
"48-bit things" related to porting, in which case I would think that you 
could put your implementation in java.nio as package-private classes.

> 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?
>
You'll need to use a weak or phantom reference to know when the 
ByteBuffer is GC'ed.

> 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?
>
Is this a problem? The main rational is to keep the native code to a 
minimum and also to avoid a malloc/free per call that involves a path 
name. It does have an optimization for cases where you are doing lots of 
operations on the same file name but that isn't as significant.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20120821/1f562423/attachment.html