New NIO code needs refactoring

Wed Mar 17 12:08:00 GMT 2004

Michael Koch wrote:
> while trying to merge your new cool NIO code into GNU classpath I found 
> out that it relies on the this old GCJ bug that allows accessing 
> package-private classes in other packages.

I was at first confused, but I think you mean that CNI allows you
to bypass strict Java access-control. That's not necassrily a bug;
it does conpendate for teh lack of "friend".
> Jikes doesnt allow this and its not valid either.

This is what made me think you were talking of the gcj compiler, but
you're actually talking about gcjh and g++, I think.
> I ran into this issue months ago too and moved 
> gnu.java.nio.channels.FileChannelImpl to java.nio package.

The problem with that is that FileChannelImpl needs to be accessible
from java.io, for FileInputStream etc.
> Can you refactor your code to allow comilation with jikes please ?

I tried the obvious solution of moving MappedByteBufferImpl to
gnu.java.nio, but that requires moving DirectByteBufferImpl and
ByteBufferHelper as well. And then I assume we'll run into
problems with needin access to fields. That's probably solvable,
but bottom line it's hard to do it without cheatin somewhere.
> And someone really needs to solve this issue.

I'm not sure there's an actual problem. You're trying to write
in Java that might require native methods.
I'll do some more experiments moving classes around.
-- 
	--Per Bothner
per@bothner.com http://per.bothner.com/