java.net: Classpath vs. libgcj Comparison

Tue Apr 18 18:26:00 GMT 2000

Tom Tromey wrote:
>> >>>>> "Jeff" == Jeff Sturm <jsturm@sigma6.com> writes:
>> Jeff> Also, java.net.SocketInputStream and SocketOutputStream are
> Jeff> classes I was going to propose for libgcj, since the current
> Jeff> assumption that sockets can be represented by FileDescriptors
> Jeff> just isn't portable (win32 at least has a completely separate
> Jeff> API for socket I/O).
>> It seems like we'd have to hide this underneath FileDescriptor.
> E.g., add a flag and have the Windows implementation switch calls at
> runtime.

Ewww. This is a case where I like the Classpath implementation better. 
They don't try to treat a socket as a FileDescriptor. Instead the
PlainSocketImpl defines native methods for all socket operations, so the
native implementation is localized to one class.
I did about the same in my local libgcj workspace, but instead of
hacking PlainSocketImpl I created a custom Win32SocketImpl and installed
a Win32SocketImplFactory. Although it works, I didn't end up liking it
in the end... too much effort for a simple port.
In truth there are already two ports in java.net: the default BSD-socket
implementation, and the null implementation (activated by the
DISABLE_JAVA_NET macro). This should probably in a separate file
anyway, and we can create port-specific versions of natInetAddress.cc,
natPlainDatagramSocketImpl.cc and natPlainSocketImpl.cc.
My preference would be to add the necessary read/write methods into the
existing PlainSocketImpl and just delegate them to a FileDescriptor when
appropriate.
--
Jeff Sturm
jsturm@sigma6.com