Recently I was looking for a JDBC driver for SQLite. I always tend to prefer pure Java drivers, as my development environment is on Mac OS X, Linux and even at times Windows, so not having to recompile the library used by the driver (through JNI) on every platform I use and having the freedom of bundling the JAR file of the driver with my JARs saves me a headache. Foolishly, I searched for a pure-Java SQLite driver, forgetting that it's an embedded database in C, meaning it shouldn't technically exist.
Well, until I discovered SQLiteJDBC, which is available in both JNI (faster) and 100% pure Java. Uh, what? How is that even possible? Well, the author, used tool that makes a binary translation of MIPS object code to Java bytecode, called NestedVM. Basically, anything you can compile for the MIPS chip can be translated to Java, including all your memory leaks and buffer overflows.
Of course, that won't work well if your code depends on too much system calls (because you'll have to rewrite them all in Java) or if your code is sensitive to endianness, since both MIPS and Java are big-endian while x86 is little-endian.
Still, this is perfect for those weird audio and video codecs (performance will have a hit, but it works), obscure compression engines, encryption, weird network protocols, etc. And if you didn't got it yet, it works for any language (C, C++, D, C#, Haskel, whatever).
Also, if you implement the missing system calls you need in Java, there's noting stopping you from using GCJ to compile your system calls to native code, while keeping your native MIPS library in native code, thus maximizing performance in a simple recompile.
My dream with this is to have a Java implementation of the Apache Portable Runtime (APR), or at least one that would compile against the limited set of system calls already provided by NestedVM. That way, I would have a "rich" runtime environment, and it would make it really easy to port anything code development using (exclusively) APR into pure Java. There's also this dream of combining that with a Java implementation of the X server like WeirdX, a new X client implementation and some window manager to have a real Java desktop...