Correction for java.net

[Godmar Back]

 Archie,

> 
> Godmar Back writes:
> > I think that the values for SocketOptions do not have to match those 
> > for JDK 1.1.5 since SocketOptions is an interface that is not public.  
> > User programs can only access that stuff via Socket.setTcpNoDelay() etc.
> > In fact, the SocketOptions interface is not even documented in the JDK doc.
> > (At least not in 1.2beta3, which I have in front of me.)
> > Why do you think we need to match Sun's numbers?
> 
> It is documented in JDK 1.2 beta4 on this page:
> 
>   http://java.sun.com/products/jdk/1.2/docs/api/index.html
> 

It says:

    The methods and constants which specify options in this interface are 
    for implementation only. If you're not subclassing SocketImpl or 
    DatagramSocketImpl, you won't use these directly. There are type-safe 
    methods to get/set each of these options in Socket, ServerSocket, 
    DatagramSocket and MulticastSocket. 

 
> 
> It might be good to make them consistent, in case some compiler
> somewhere optimizes and puts the constant values in the class file
> or something... ?
> 

 Yes, the compiler inlines final ints.
That means that any alternate implementation of SocketImpl and 
DatagramSocketImpl would have to compiled against Kaffe's java.net.
User programs won't use them and won't be affected.

So, in order to be 1.2beta4 compliant, does one have to support
pre-compiled alternate implementations of subclasses of 
java.net.(Datagram)SocketImpl?  That is the question.

I think it's highly unlikely that such alternate implementations will
work with Kaffe (without recompiling them), but for the sake of retaining
a small chance that they do work, we can use the same numbers.

Now if somebody could download 1.2beta4 and write a test program that prints
out the values for SO_RCVBUF and SO_SNDBUF...

	- Godmar