"David S. Miller" wrote:
>
> Date: Wed, 18 Oct 2000 17:20:22 -0600
> From: Matt Peterson <mpeterson@calderasystems.com>
>
> Assuming that my "compatibility argument" is not considered valid.
> What I really need is some good ammunition for going back to Sun to
> ask them to change the JRE spec -- like some significant kernel
> features or Linux applications that relies on this new bind()
> behavior.
>
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
>
> Really, when an application feeds a specific address into bind() it
> must have good reason for selecting it. All I want to know in this
> specific instance, is why Sun's JRE is sending non-local addresses
> into bind(), that's all.
>
> Later,
> David S. Miller
> davem@redhat.com
The JVM is simply running the appropriate native code for bytecodes that
represents the java.net.DatagramSocket(int port, InetAddress laddr)
constructor. Documentation for this constructor reads "Creates a
datagram socket, bound to the specified local address." What do you
expect the JVM to will do? It trys to bind() to the supplied address
and port. There are no bugs here. java.net.DatagramSocket is just
trying to emulate the expected Sockets interface behavior. The Sun JVM
compatibility test suite appropriately includes some test to ensure that
error conditions are handled correctly. Supplying a non-local IP
address to bind() is an error condition. Hence, the JVM fails
compatibility on Linux 2.4.
-- Matthew Peterson Sr. Software Engineer Caldera Systems, Inc mpeterson@caldera.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:15 EST