This is just transcompilation to Java, not actual static compilation. The performance gains will be offset by the increased memory footprint of the JVM.
Interesting nonetheless.
Interesting nonetheless.
A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (other than through invokedynamic, which does work very well).
Instead, this is using a static view of the world to produce the resulting code...assuming only the method names it sees statically at compile time will ever exist, and generating a static picture of that world. Hell...it's actually turning all dynamic dispatch into static dispatch. How could a transcompiler possibly do that?
Also...performance gains being offset by the size of the JVM? I don't understand this at all.
This isn't static compilation in any sense of the definition as you're not producing a low-level language, i.e. assembly or machine code. Ultimately the JVM will do some combination of static and JIT compilation, but your code isn't doing this.
In no way am I deriding your effort, you've just got your definitions mixed up.
The JVM tends to run in a relatively large memory footprint compared to the MRI, although the JVM will execute faster when it's warmed up. The JVM isn't known for being frugal when it comes to memory usage. For long running processes, your transcompiler could be very useful.
Transcompilation can be relatively simple in the case of CS to JS, or significantly more involved in the case of Ruby to Java. One of the most significant examples of transcompilation is PHP to C++, as in the case of Facebook's HipHop compiler.
FWIW, I'm probably going to just emit JVM bytecode anyway, since it's easier than emitting syntactically correct Java source.
Something is considered source code if it is intended to be written and read primarily by humans. Once upon a time, machine code would have been the same as source code as there were no compilers, and punchcards were punched with opcodes and data directly. Now, nobody in their right mind considers machine language to be source code, and I could only make a very tenuous argument in favor of JVM bytecode being source code.
Compilation is the process of producing something the "machine" understands natively. Traditionally this was the CPU. Your CPU doesn't understand Ruby, but it (probably) understands x86 machine code, along with various extensions. In the case of Java, the machine is no longer the CPU, but an abstraction of it. The machine in this case only understands JVM bytecode, not Java. Same with the CLR which only understands IL, not C#, F#, VB.NET, etc.
If you emit bytecode directly you'd have a compiler not a transcompiler.
JRuby is an actual compiler to JVM bytecode. FastRuby is translating to Java. If anything, FastRuby is the SAME THING as CoffeeScript.