Re: java.net: Classpath vs. libgcj Comparison

[Jeff Sturm <jsturm at sigma6 dot com>]

Per Bothner wrote:
> 
> Bryce McKinlay <bryce@albatross.co.nz> writes:
> 
> > When I was looking at this a while ago I came to the conclusion
> > that we do in fact need to have seperate outputstream code for Files and
> > Sockets, at least at some level. The problem of File descriptors not
> > being a portable way to represent sockets seems to add weight to this.
> 
> They don't have to be, and were not intended to be.  Having the
> SocketImplFactory and SocketImpl framework were designed to handle
> different SocketImpl sub-classes.  For Windows, we need to define a
> WindowsSocketImpl class, and install things so that creating a socket
> returns a WindowsSocketImpl rather than a PlainSocketImpl.  It might
> make sense to rename the latter to UnixSocketImpl or something, but I
> see no reason why the existing class can't continue to use
> FileDescriptor (except perhaps the timeout issue someone mentioned).
> We should probably also create and installed an explicit
> UnixSocketImplFactory rather than having that be implicit.

It's not clear what Sun intended SocketImplFactory for, but that could
certainly work.  As I was telling Tom, that's basically what I did in my
local copy while hacking on Windows support.

The DatagramSocket class works slightly different, it doesn't use a
factory class but instead uses a system property, impl.prefix, to
resolve the implementation class name.  The name of the default socket
factory could be a system property as well.

I'd argue that the platform-specific classes shouldn't be in java.net at
all, they could be moved to a package like gnu.gcj.net to avoid
cluttering the java.net namespace.

A nice feature of the factory pattern is that platform-specific classes
don't have to be compiled at all where they are not needed, such as the
Win32 classes on Unix.

--
Jeff Sturm
jsturm@sigma6.com