New NIO code needs refactoring

Tue Mar 23 12:51:00 GMT 2004

Michael Koch wrote:
> Found 4 semantic errors compiling 
> "/home/mkoch/src/classpath/java/nio/channels/FileChannelImpl.java":
>> 49. import java.nio.MappedByteBufferImpl;
> ^---------------------------^
> *** Semantic Error: The type "java.nio.MappedByteBufferImpl" has default 
> access and is not accessible here.

I'm still a bit confused. This code is not in libcj - it's only
in your "port" of the libcj code. Specifically, FileChannelImpl
in libgcj is in gnu.java.nio.channels - and it does not import
MappedByteBufferImpl.
However, natFileChannelPosix.cc does "import" MappedByteBufferImpl,
which does "violate" Java access control, but I think that is
inevitable and ok - technically we should tell gcjh to add
"friend" specifiers, like we do elsewhere in libgcj.
It seems to me you'll need a "backdoor" to DirectByteBufferImpl
or the equivalent to implement the JNI method NewDirectByteBuffer.
Perhaps a solution, if you want maximally portable Java code, is
to use some indirection: a MappedByteBufferImpl that forwards to
a direct buffer allocated by NewDirectByteBuffer.
I'm leaving for Europe tomorrow, and won't be back until April 8.
While I'l bring my PowerBook and I'll have internet access, it
would be just to cumbersome to try to work with you on a solution.
Especially, since I'm not convinced there is anything wrong with
the current layout - given the impossible constraints Sun has put
on us! I think the solution is to use JNI/CNI to bypass Java
access control.
-- 
	--Per Bothner
per@bothner.com http://per.bothner.com/