18 comments

[ 5.2 ms ] story [ 50.5 ms ] thread
There are currently two open source AOT compilers RoboVM and avian that can be used for cross-platform iOS/Android development. Both seem to be in pre-alpha state. Seems like a better option would be to use apportable and go the other way from iOS to android. Anyone here have any experience with these?

http://oss.readytalk.com/avian/

http://www.apportable.com/

I rememberer long time ago when i was still in the land of Java I researched the topic there were GCJ as well. Dont know what happened to it And Something called ExcelsiorJET as well.
GCJ is dead, as most developers went away to OpenJDK or just lost interest.

Besides ExcelsiorJET, Aonix and IBM Webpshere Real Time VM do also offer AOT compilation.

Let's not forget that RoboVM is still alpha, and on Sept 09th version 0.0.4 was released: http://blog.robovm.org/2013/09/robovm-004-released.html

Here's an interesting blog post on RoboVM: "JavaFX On IOS Using RoboVM And Maven" http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm...

Niklas, the author or RoboVM, just send his first submission to the App Store, we'll see how that pans out. In the meantime, lots of folks from the libgdx community (JVM game dev framework) already ported many non-trivial games to RoboVM, without any big issues, e.g. [1][2]

Current limitations: no debugging, Boehm GC (though anything except stack references are collected precisely) and the ObjC -> Java bindings are a bit in flux.

I personally would like to see the ObjC bindings ala Xamarin get done. JavaFX is a trainwreck in my opinion. I think that would also be a really good business opportunity for Niklas/Trillian, i can see tons of enterprises wanting to code their iOS apps via a JVM language. RoboVM already has Maven/STB plugins available, so development is very smooth. And compile times beat Xamarin easily.

What gets me really excited is that RoboVM supports Scala out of the box. Writing iOS/Android/desktop games and apps in Scala would be amazing.

[1] http://www.youtube.com/watch?v=h0Ro41uamD0 [2] https://twitter.com/RainerBasso/status/378621566206369792

It compiles the Java but what about the big VM needed?

Found my answer: Note! When you compile a program using RoboVM it will translate not only the main class into native code but also the transitive dependencies of that main class. So the first time you compile a program for a particular CPU and OS RoboVM also compiles many of the standard runtime classes such as java.lang.Object, java.lang.String, etc. A simple class like HelloWorld references about 1500 classes directly or indirectly. RoboVM keeps a cache of compiled classes and only recompiles a class when it or any of its direct dependencies have changed.

Wow

This is exciting. But wouldn't this result in very large final binary sizes?
Yes and no.

This can happen even in languages like C when you do static linking.

The solution is to have the linker remove all code that is not being called. The consequence of it, it that you are restricted in doing reflection, for example.

Some Java native compilers allow you to provide a list of methods to leave alone, to avoid them being removed from the final executable.

Should be able to use ProGuard, a code obfusticator+trimmer for Java. http://proguard.sourceforge.net/

Although, from my experience doing Android with Scala, the process is slow.

"Read a few links on HN" slow, or "time to make some coffee" slow?
You only need it a few times when getting ready for distribution.
What is large? Also, looking at software history, it will actually be cool in a few years to make binaries as large as possible. Files with random crap in them should be normal by then to show that you are the best value for money!
Why is this so special?

This is basic compiler design 101.

The Java VM is just a possible implementation for the Java language.

The fact that many mix "Java the language", with "Java the Virtual Machine", is a consequence of the lack of knowledge in compiler design that seems so common nowadays.

Though I'd generally agree with your last statement (and relish in the amazement on one's face when I show them disassembled JVM bytecode for the first time), I'd have to say that this is still quite a "special" feat whether you've written a virtual machine/compiler/interpreter before or not. I haven't had enough time with the source as of yet, but I'd wager to say that there is most likely a lot more going on than just caching already-cross-compiled classes or basic opcode mappings. Not to forget that this project looks to be quite literally implementing from the JVM spec (a la Apache Harmony).
Anyone knows if roboVM is using the same approach as MonoTouch uses ? I've always been curious to know how those two operated.

Do they link iOS frameworks C libraries and just provide wrappers in a C# or Java lib (which are then compiled to bytecode then native) ?