This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: java.net: Classpath vs. libgcj Comparison


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]