This bug documents a situation I was just discussing with Dave Brown, and it is
the real cause of P1 bugid 4026810 for RMI, although a somewhat awkward
workaround is being provided to (mostly) fix that bug. Dave said that he will
look into it. (Thursday, 7:45PM EST)

When Java code consumes up all of its process's file descriptors, the VM is no
longer able to load any classes. Therefore, when an attempt is made to acquire
another file descriptor, it is likely that the proper exception class cannot be
loaded, and a NoClassDefFoundError is thrown instead.

For example, if a server is executing a ServerSocket.accept() call to accept an
incoming client connection, and there are no free file descriptors, it cannot
load "java.net.SocketException" to signal this condition, so the
NoClassDefFoundError is thrown. It is unlikely that the application code is
programmed to deal with this error at the proper level to sensibly recover its
server operations (this error is usually considered fatal in the general case).
To make matters worse in this instance, this error bypasses the catch for
an IOException in ServerSocket.implAccept() so the server socket is not closed,
as the application would expect on failure. Therefore, a whole bunch of clients
might be able to successfully connect to the port that the server was listening
on, and they will all hang waiting for a response to the server.

The server would have to explicitly catch this NoClassDefFoundError and assume
this failure to properly recover, or at least close the server socket.

Outside of specific sections of code expecting it, the NoClassDefFoundError is
usually considered a fatal condition that the application cannot proceed with.
Running out of file descriptors, however, is a condition which many programs
will need to be able to handle in a graceful fashion. Not being able to load
any other classes (like application specific exception types) and having to
catch NoClassDefFoundError make this handling tedious to accomplish.