This is the mail archive of the 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: Classpath vs. libgcj Comparison

Tom Tromey wrote:
> >>>>> "Jeff" == Jeff Sturm <> writes:
> Jeff> Also, 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 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, and

My preference would be to add the necessary read/write methods into the
existing PlainSocketImpl and just delegate them to a FileDescriptor when

Jeff Sturm

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