>>>>> "Nic" == Nic Ferrier <[EMAIL PROTECTED]> writes:
Nic> java.net.SocketInputStream Nic> java.net.SocketOutputStream Nic> In the end I opted for inner classes because separate streams Nic> seemed to confuse the API. Seems sound. Note that the classpath/libgcj comparison script is a bit stupid. It doesn't look to see whether the classes are public, but just blindly proceeds based on the package name. Nic> Would the Classpath people like me to add timeout code to their Nic> Socket implementation? Nic> If so, would it also be okay to remove the stream classes and Nic> make them inner classes (of PlainSocketImpl). That should clear Nic> them off the merge list. The long-term goal is to have all the java.net code shared between libgcj and Classpath. I haven't looked to see whether java.net is difficult to merge. My experience in merging, generally, is that classes with native methods tend to be a bit problematic, as are classes that rely on behind-the-scenes infrastructure (that's why the java.io classes that need encoding transformations aren't merged). For some packages it is pretty easy to merge classes piecemeal. If you're interested in merging any of java.net, that would be great. Our approach to merging has been to try to make sure that the merged class retains the best attributes of the two original classes. Tom _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
