The rmi spec(which is hardly a spec) should not be dictating the exception checking, as its the ejb specs which define what is needed. Allowing superclasses of RemoteException is obvisously going to collide with generic application exceptions. The ejb spec is pretty clear about remote methods must be identified by a RemoteException, with any number of application exceptions.

The current throwsRemoteException(Method) method is a confusion of checks that are mixing local and remote interface semantics:

 /**
 * Checks if the method includes java.rmi.RemoteException or its
 * subclass in its throws clause.
 *
 * See bug report #434739 and #607805
 */
 public boolean throwsRemoteException(Method method)
 {
 Class[] exception = method.getExceptionTypes();

 for (int i = 0; i < exception.length; ++i)
 {
 // Fix for bug #607805: an IOException is OK for local interfaces
 // Fix for bug #626430: java.lang.Exception is also OK
 if (exception.equals(java.io.IOException.class)
 || exception.equals(java.lang.Exception.class))
 {
 continue;
 }
// Not true see bug report #434739
// if (java.rmi.RemoteException.class.isAssignableFrom(exception))
 // According to the RMI spec. a remote interface must throw an RemoteException
 // or any of its super classes therefore the check must be done vice versa

 if (isAssignableFrom(exception, "java.rmi.RemoteException"))
 {
 return true;
 }
 }

 return false;
 }

public interface X extends EJBObject
{
 void m0() throws IOException;
 void m1() throws Exception;
 void m2() throws Throwable;
}