4 ms·

This is extremely exciting. I can't wait to try this out. On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it wa

by kentosi 10y ago

This is extremely exciting. I can't wait to try this out. On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

wtetzner 10y ago
There was RoboVM[1], but it looks like it shut down. GCJ [2] was GCC's Java implementation, which was natively compiled, but I think has been removed from GCC. I'm sure there are other projects. [1] https://robovm.com/ https://robovm.com/ [2] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java https://en.wikipedia.org/wiki/GNU_Compiler_for_Java
- invalidname 10y ago
  Codename One predated RoboVM, was always larger and is still open source and well supported: https://www.codenameone.com/ https://www.codenameone.com/
david-given 10y ago
Would this be a good time to mention that a few years ago I wrote an experimental Java AOT compiler which worked by converting bytecode into C++? http://cowlark.com/cowjac http://cowlark.com/cowjac I used Apache Harmony as the standard library, and binaries were about 2MB, which back in 2012 I considered unacceptably large; benchmarks were adequate only. I never got round to implementing a garbage collector but the hooks were in place for a simple mark/sweep stop-the-world collector. The hard part would be to actually make all threads of the program stop so they could be collected; I had a plan, but no implementation. Interested parties may also be interested in my experimental Java JIT which worked by converting bytecode into Lua and then running it with LuaJIT: http://cowlark.com/luje http://cowlark.com/luje It actually beat OpenJDK Server for some unrepresentative microbenchmarks. It's very unfinished, and generates fairly pathological Lua code which LuaJIT has trouble with, but the biggest problem is that Lua and LuaJIT can't do shared-memory threading, so most Java code won't work on it. (JVMs are surprisingly easy to write. If you're interested in interpreters or code generation, I encourage you to try it.) (Man, I completely forgot I wrote these until now!)
twic 10y ago
It was. Several times. It didn't take off for two reasons. Firstly, it's not really any faster than a good JIT, and Java has very good JITs. The startup time is better, but the startup time of a JVM itself is actually pretty small ('time java -cp . HelloWorld' prints 'real 0m0.112s' on my machine), and for the uses Java is usually put to, irrelevant. I'd be very interested to see some benchmarks for Scala Native. Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM.
- invalidname 10y ago
  For mobile all of these don't apply. The mobile version of Java doesn't include as much dynamic stuff and doesn't require dynamic loading so you can build a really efficient AoT compiler e.g. https://www.codenameone.com/ https://www.codenameone.com/ The core JDK makes those assumptions and is indeed a bad candidate for AoT OTOH so is scala and it will prove very difficult to provide any value beyond what the JDK already offers.
- lmm 10y ago
  > Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM. The key advantage of Scala in general is that these things are rarely necessary - the fancy type system and generally expressive language make it much easier to address the use cases with "vanilla" Scala instead. So Scala Native will hopefully be able to bypass this issue.

by kentosi 10y ago

This is extremely exciting. I can't wait to try this out. On the other hand, I wonder why such an effort was never carried out with Java itself? Or maybe it was but just never took off?

wtetzner 10y ago

There was RoboVM[1], but it looks like it shut down. GCJ [2] was GCC's Java implementation, which was natively compiled, but I think has been removed from GCC. I'm sure there are other projects. [1] https://robovm.com/ https://robovm.com/ [2] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java https://en.wikipedia.org/wiki/GNU_Compiler_for_Java

invalidname 10y ago
Codename One predated RoboVM, was always larger and is still open source and well supported: https://www.codenameone.com/ https://www.codenameone.com/

david-given 10y ago

Would this be a good time to mention that a few years ago I wrote an experimental Java AOT compiler which worked by converting bytecode into C++? http://cowlark.com/cowjac http://cowlark.com/cowjac I used Apache Harmony as the standard library, and binaries were about 2MB, which back in 2012 I considered unacceptably large; benchmarks were adequate only. I never got round to implementing a garbage collector but the hooks were in place for a simple mark/sweep stop-the-world collector. The hard part would be to actually make all threads of the program stop so they could be collected; I had a plan, but no implementation. Interested parties may also be interested in my experimental Java JIT which worked by converting bytecode into Lua and then running it with LuaJIT: http://cowlark.com/luje http://cowlark.com/luje It actually beat OpenJDK Server for some unrepresentative microbenchmarks. It's very unfinished, and generates fairly pathological Lua code which LuaJIT has trouble with, but the biggest problem is that Lua and LuaJIT can't do shared-memory threading, so most Java code won't work on it. (JVMs are surprisingly easy to write. If you're interested in interpreters or code generation, I encourage you to try it.) (Man, I completely forgot I wrote these until now!)

twic 10y ago

It was. Several times. It didn't take off for two reasons. Firstly, it's not really any faster than a good JIT, and Java has very good JITs. The startup time is better, but the startup time of a JVM itself is actually pretty small ('time java -cp . HelloWorld' prints 'real 0m0.112s' on my machine), and for the uses Java is usually put to, irrelevant. I'd be very interested to see some benchmarks for Scala Native. Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM.

invalidname 10y ago
For mobile all of these don't apply. The mobile version of Java doesn't include as much dynamic stuff and doesn't require dynamic loading so you can build a really efficient AoT compiler e.g. https://www.codenameone.com/ https://www.codenameone.com/ The core JDK makes those assumptions and is indeed a bad candidate for AoT OTOH so is scala and it will prove very difficult to provide any value beyond what the JDK already offers.
lmm 10y ago
> Secondly, there's enough dynamic code in the Java ecosystem - bytecode weaving, dynamic proxy generation, plugin classloading, etc - that in practice, your AOT-compiled application need to have an interpreter along for the ride anyway. That means you don't even save the space overhead and distribution complexity of deploying a JVM. The key advantage of Scala in general is that these things are rarely necessary - the fancy type system and generally expressive language make it much easier to address the use cases with "vanilla" Scala instead. So Scala Native will hopefully be able to bypass this issue.