New NIO code needs refactoring

Michael Koch
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
> > to java.nio package.
> The problem with that is that FileChannelImpl needs to be accessible
> from, for FileInputStream etc.
> > Can you refactor your code to allow comilation with jikes please ?
> I tried the obvious solution of moving MappedByteBufferImpl to
>, 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.
(sorry, I cant find the original mail from Ranjit in the webinterface 


More information about the Java mailing list