Static typing, no workarounds

A simultaneous benefit and curse of loosely-typed languages (Perl, Ruby, Javascript, etc) is that a programmer can do just about anything with a third-party library. The ability to “fix” into other people’s code running in the same process is sometimes called “monkeypatching”.

Stricter languages, like Java, make it dramatically harder to accomplish the same goals. This is intentional, because Java also allows sandboxing of untrusted code in the same code space (pretty much impossible in existing dynamic languages despite efforts).

But what do you do if there is a problem with the third-party code and you can’t change it? In Java, you may just be screwed. For example, the Apache River distributed computing SDK uses “throws java.rmi.RemoteException” as a hint about which server methods are allowed to be invoked from the client. But, oops, Android’s Dalvik VM omitted all of the java.rmi.* classes to save resources. So trying to load a class with that “throws” declaration causes a “NoClassDefFoundError”. Because there’s no way to inject a third-party class into the “java.*” packages space, and Android developers have not been willing to add this simple Exception to Dalvik, this effectively kills all reasonable hopes of using River on Android. The River folks even talked about extreme hacks of rewriting the classes on load, but that’s too impractical. The answer from Android fans in scenarios like this seems to be “Why do you want to use that library anyway?

A dynamic language would have just created a stub for that exception if it didn’t exist. Is that better or worse?