The 'anything goes' SecurityManager

As previously mentioned, my current 20% project involves some RMI hackery. Today I ran into an unfortunate error message:
java.lang.ClassNotFoundException: com.publicobject.m2x.Measurer (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(
at sun.rmi.server.LoaderHandler.loadClass(
at java.rmi.server.RMIClassLoader$2.loadClass(
at java.rmi.server.RMIClassLoader.loadClass(
at sun.rmi.server.MarshalInputStream.resolveClass(
Apparently Java RMI won't let me download remote code without a security manager installed. The standard workaround for this problem is to create a .policy like so:
grant {
. . . and then I need to reference the file when I launch the app:
java -cp . com.publicobject.m2x.Main
I don't like this solution because it forces me to change how my app is launched, complicating deployment. It adds another file to manage. And the deployment work needs to be solved in Unixland, far from my comfort zone of Javaland.

It turns out I can do the same thing in Java code by installing a no-op security manager:
    System.setSecurityManager(new SecurityManager() {
public void checkPermission(Permission permission) { }
public void checkPermission(Permission permission, Object context) { }
I like this better.

Java should be first on the Java Platform

When designing APIs for the Java platform, programmatic access must be a first-class citizen. APIs that require XML, configuration files, or System properties shouldn't be the only way to access functionality.
I wish they would have thought of that when they created JEE.