New NIO code needs refactoring

Wed Mar 17 12:45:00 GMT 2004

Am Mittwoch, 17. MÃ¤rz 2004 08:01 schrieben Sie:
> 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".

No, I mean that GCJ allows access package-private stuff (not only 
classes) in other packages in Java code. Jikes doesnt allow this.
> > 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.

Thanks for doing this. I fiddled around with this several times already 
when I tried to merge our code into GNU classpath.
Also Ranjit solved this issue by a bad hack (it was never accepted) some 
time ago. http://gcc.gnu.org/ml/java-patches/2003-q3/msg00318.html
(sorry, I cant find the original mail from Ranjit in the webinterface 
anymore)
Michael