This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: New NIO code needs refactoring
- From: Per Bothner <per at bothner dot com>
- To: Michael Koch <konqueror at gmx dot de>
- Cc: java at gcc dot gnu dot org
- Date: Sun, 21 Mar 2004 09:32:10 -0800
- Subject: Re: New NIO code needs refactoring
- References: <200403161358.46512.konqueror@gmx.de>
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/