There are some rough edges in the ways that security permissions are used by the internal implementation of RMI class loading in 1.2 FCS.

One example is when a server is unmarshalling parameters to an RMI call, if a class descriptor is encountered with a codebase that the server does not have permission to connect to, the unmarshalling will fail with a ClassNotFoundException (containing a security exception) *even if* the class can be resolved by name through the server's context class loader. This is due to an optimization does between beta4 and FCS where the internal MarshalInputStream simply calls RMIClassLoader.loadClass() with the class name and supplied codebase, depending on the 1.2 class loader delegation hierarhy to find class locally (system class or in the context class loader) before attempting to load from the network codebase. The problem is that RMIClassLoader.loadClass() enforces the permissions necessary to connect to its codebases on all invocations of loadClass(), even if the named class can be found in one of its ancestor class loaders. In beta4 and previous JDK version, the context class loader was separately consulted first, avoiding the RMIClassLoader permission check, but that meant that it (the context class loader) would be consulted (at least) twice, which had a noticeable performance impact. But the permission restriction resulting from this optimization seems wrong, so this needs to be fine-tuned a little more.

This problem can happen in simple RMI applet/server communication if the server code does not have permission to connect to the codebase that the applet gets loaded from, and the applet passes the server objects of some of its own types found in its codebase: those types will get annotated with the applet's codebase, and even though the server has them in its class path, it will fail to resolve them because it doesn't have permission to connect to that extraneous codebase (if there wasn't even a codebase annotation, it would work fine). The workaround, in this case, of granting the server that permission does not seem terrible because the server and its associated applet classes should be friendly with each other.

Another example is that the actual class loader type used by RMI does not override getPermissions() in any purposeful way, and the result is that code downloaded from a JAR file at a "file:" URL does not automatically get permission to load code from other JAR files referred to by the first one, even if they are located in the same directory. The internal applet class loader solves this problem by overriding getPermissions() so that if a class's code source is a "file:" URL, then in addition to read that exact URL (as granted by URLClassLoader), it also grants permission to (recursively) read all files in the same directory. Perhaps the RMI class loader implementation should be doing the same thing.