Re: JNI/CNI Revisited

[Aaron M. Renn]

Jeroen Frijters (address@hidden) wrote:
> >   void nativeSync(long fd) throws SyncFailedException
> 
> I really don't like this model, because it forces the VM into using a
> long for the file descriptor. IMHO a better alternative would be to have
> instance methods in java.io.FileDescriptor that call a static native.
> 
> class FileDescriptor
> {
>   private long fd;
> 
>   void sync() {
>     nativeSync(fd);
>   }
> 
>   private static native void nativeSync(long fd);
> }
> 
> This allows VMs (such as mine) that don't use an integer as a file
> handle, to replace FileDescriptor with a different implementation, but
> leave all other i/o classes as is.
> 
> There is a tiny overhead in this approach, but I think it is worth it
> (but then, I'm biased ;-)).

Can you explain this further?  I'm not clear on the problem, exactly.
In your example, everything is still long.  If you changed your instance
variable to an int, I don't know what that buys us.

For cases where we might have architectures that don't use traditional
file descriptors or require storing lots of state information, my
thought was that the long fd value just becomes a handle you use to
access native information.  I believe that somewhere in the bowels
of Classpath, there is a library of helper functions for doing this.
In really offbeat cases, there may be no alternative to but replace
FileDescriptor completely.

-- 
Aaron M. Renn (address@hidden) http://www.urbanophile.com/arenn/