Re: gcj vs classpath merge status

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nic" == Nic Ferrier <nferrier@tapsellferrier.co.uk> 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