Robert Schuster wrote: > Hi all, hi Casey. > > As discussed earlier I am investigating the removal of the above class. In > contrast to what I said in another mail I found two uses of the > VMPlainDatagramSocketImpl. > > In PlainDatagramSocketImpl the IP_TTL field is used. This can be fixed by moving > the constant into e.g VMPlainSocketImpl or VMChannel. When doing so the > constant's name should be changed to something like CP_IP_TTL because it would > otherwise conflict with a constant in the system headers when using the class in > GCJ. > > Still there is something to find out: The IP_TTL constant is used for the > VMPlainSocketImpl.setOption method. The JNI code for that method contains a big > switch statement, but there is no case for IP_TTL. > > Should it simply be added? > Yeah. What the setOption method tries to do now is put "integer" methods (those that set an integer or a boolean value) in one method (in VMPlainSocketImpl), and to get/set other values with dedicated methods. Getting the bind address, for example, has it's own method (getLocalAddress). This is probably not the best way to do this, though. This favors simpler native methods (always passing and returning an integer value is a lot easier than dealing with different argument types), but in this case I'm not satisfied with it. > The other thing that is used from VMPlainDatagramSocketImpl is the connect() > method. Is it possible for DGRAM sockets to just use VMChannel.connect instead? > Yes. The original just called the common method _javanet_connect, anyway.
