Nice thought, and yes it's possible and has been done.
Oracle's Hotspot JVM goes for a JIT (Just In Time) strategy, but there are other JVM's that take an AOT (Ahead of Time) compilation strategy. http://www.excelsiorjet.com/ is one example.
But I don't agree that you can do away with the JVM itself. Even if your java code is compiled into native machine code, it still needs all the stuff JVM provides other than JIT compiler - things like memory allocation, GC, thread synchronization primitives, class loading, reflection, management counters.
Well, with native compilation, all that could be compiled into the resulting binary. Oracle is actually planning something similar for Java 9, where you can create a deployable that's a subset of the JVM (including its own java.exe on Windows). It's not a binary though.
Rob Spoor wrote:Well, with native compilation, all that could be compiled into the resulting binary.
But the memory used by the JVM to store all the state that enables it to provide those additional services can't be avoided, even if the JVM's code was linked along with the app into a single binary.
I think OP's assumption was that compiling to native code would avoid the JVM's memory footprint, making it suitable for low memory devices like Arduino.