On Thu, 3 Jul 2003, Ian Clarke wrote: : That is unfortunate - we went ahead with NIO because there are Open : Source implementations out there - although they still need work.
The only ones that support NIO, to my knowledge, are gcj and Classpath. * gcj works reliably on even less platforms than Sun's own JDK (and is even less reliable with Freenet in particular, from my experience compiling it at work on Loonix) -- it's a write-off at the moment; * Classpath doth not a JVM make, so its classes have limited usefulness without external support that hooks into a JVM's java.io and java.net. However. I'll see if there is some hope for bringing in Classpath's java.nio.* implementation as an optional extension JAR file. The catch is that the following methods are unavailable in this arrangement, requiring classical streams to be channel-wrappered instead: * java.io.FileInputStream.getChannel() * java.io.FileOutputStream.getChannel() * java.io.RandomAccessFile.getChannel() * java.net.Socket.getChannel() Which means that FileChannel and SocketChannel aren't actually usable (including FileChannel.map(), FileChannel.lock, and the SelectableChannel portion of both of these), though ReadableByteChannel and WritableByteChannel would be. I haven't looked to see how feasible doing wrappering would be, but would you be happy with an extension JAR based on Classpath java.nio.*, and necessary diffs (detection of methods, and use of wrapping where needed) to make Fred usable again with pre-1.4 JVMs? sigh ... JDK 1.4 is known to be simply not stable in too many situations, and I fear for the capacity of Freenet because of this move. 8-( -- -- Todd Vierling <[EMAIL PROTECTED]> _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
