This is the mail archive of the
mailing list for the Java project.
Re: java.net: Classpath vs. libgcj Comparison
Tom Tromey wrote:
> >>>>> "Jeff" == Jeff Sturm <email@example.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
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