>>>>> "Aaron" == Aaron M Renn <[EMAIL PROTECTED]> writes:
Jeroen> This allows VMs (such as mine) that don't use an integer as a Jeroen> file handle, to replace FileDescriptor with a different Jeroen> implementation, but leave all other i/o classes as is. Aaron> Can you explain this further? I'm not clear on the problem, Aaron> exactly. In your example, everything is still long. If you Aaron> changed your instance variable to an int, I don't know what Aaron> that buys us. Aaron> [ ... ] Aaron> In really offbeat cases, there may be no alternative to but Aaron> replace FileDescriptor completely. I think his example code was to show how the reference implementation would look. The idea is that the FileDescriptor API would consist of instance (not static) methods, and in the reference implementation these would just call the appropriate native (static) methods. If the FileDescriptor API is done this way, then it facilitates replacing the FileDescriptor implementation, because the other classes in java.io won't have to be changed. I have a slight preference for this since it lets us make less changes in libgcj :-). But really it isn't a major point. If FileOutputStream.write(byte) is written: return FileDescriptor.nativeWrite(fd.nativeDescriptor, b); or: return fd.write(b); // Delegates to nativeWrite, like Jeroen's example ... either way a VM implementer could replace FileDescriptor, since the above doesn't depend on the type of FileDescriptor.nativeDescriptor. Still, the latter seems a bit clearer. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath