ICMP and InetAddress.isReachable()

In Java it is only possible to work with two types of sockets: stream based ones (or TCP ones - java.net.Socket and java.net.ServerSocket) and datagram based ones (or UDP ones - java.net.DatagramSocket and java.net.MulticastSocket).
The open bug 4727550 asks to support other socket types, that will allow, for example, to perform an ICMP ping and, in general, to access the sockets in raw mode.

To implement an ICMP ping, a partial solution has been introduced in J2SE 5: a way to check if some address is reachable, via java.net.InetAddress.isReachable() methods.
The implementation of these methods goes native and tries to do its best to "ping" the address represented by the InetAddress.

Surprisingly, there are many differences between the Windows and the Linux/Unix implementation of java.net.InetAddress.isReachable().

Windows, as strange as it seems, does not officially support an ICMP "ping" system call. The J2SE 5 implementation hence tries to open a TCP socket on port 7 (the echo service) and hopes to get some sort of reply.

Linux/Unix, instead, supports an ICMP "ping" system call. So the implementation of java.net.InetAddress.isReachable() first tries to perform the "ping" system call; if this fails, it falls back trying to open a TCP socket on port 7, as in Windows.

It turns out that in Linux/Unix the ping system call requires root privileges, so most of the times java.net.InetAddress.isReachable() will fail, because many Java programs are not run as root, and because the target address unlikely has the echo service up and running.
Too bad.

But why on Linux, for example, I can use the ping program without being root ?
It's because ping has the setuid bit set:

$> ls -l /bin/ping
-rwsr-xr-x 1 root root 30724 2005-11-11 01:15 /bin/ping

When a user invokes ping, it will run as root (see the "rws" permission for the owner ?).

But why on Windows there is a ping executable that does the job ?
It seems that this executable is relying on undocumented features, so everyone tries to avoid binding to those features.

So, for now, writing portable Java code that wants to send ICMP ping is quite an adventure.

Why Thread.currentThread().getContextClassLoader() ?

I recently been involved in a discussion where I questioned that Thread.currentThread().getContextClassLoader() was the right way to implement the accessibility of a ClassLoader from any point in the code from a thread.
I very much preferred that ClassLoader.getContextClassLoader() was available, thus freeing class Thread of any reference to class loading.

Other examples of accessibility of thread local information are present in the Java libraries, most notably TransactionManager.getTransaction(), that returns the Transaction currently associated with the thread (though the call is not static).
There is also a RFE for having the Locale available, see RFE 6197800.

Both follow the model of not being implemented in class Thread, so I wonder why for ClassLoader it was implemented in this way. Some historical reason maybe, and probably right now is not practical to deprecate that call in favor of ClassLoader.getContextClassLoader().

JavaDay event in Torino, July 7th

JUG Torino is proud to organize the first JavaDay conference in Torino, on July 7th.
JavaDay travelling conferences will be held (in different dates) in many major cities of Italy, and Torino is the first installment.

The conference schedule is pretty good, and features also two international speakers: Jason van Zyl of Maven fame, and Greg Wilkins of Jetty and WebTide fame.

Sessions Highlights: Object-Oriented development, Ajax, Maven, Jetty, Struts and more.

The JavaDay conference is free, just register at the JavaDay site.

See you there !