Codename One and RoboVM solve different use cases. If you can live with the limitations of a "common denominator" API, a UI toolkit that tries to mimic the native look and feel ala Swing and a limited subset of Java 5, Codename One is great since it allows you to use a single codebase and deploy to many different device types.
RoboVM on the other hand lets you use all the native iOS APIs from within Java and has a runtime library based on Android which limits you only to roughly the Java 6 APIs. As long as you structure your code properly RoboVM makes it possible to reuse large portions of your code between the Android and iOS versions of your app. So if you'd rather build an app that is truly native with a native UI and still want to be able to share code with Android RoboVM may be a better fit. And it's definitely not just for games even though libgdx+RoboVM is a killer combination.
I'm afraid that you are mistaken about the capabilities of the Boehm GC when it comes to compacting. It doesn't compact so heap fragmentation is a possibility with RoboVM. Mono 2.8 introduced SGen [0] which is a totally separate GC developed by the Mono project. It is a compacting GC and is now the default IIUC.
(I had drawn my impression of Mono from https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_a... 's current statement: "The Boehm GC is used by many projects that are implemented in C or C++, as well as by runtime environments for a number of other languages, including [...], the Mono implementation of the Microsoft .NET platform (also using precise compacting GC since version 2.8)"... which evidentially is referring to "also" a different GC entirely, rather than a mode as I had thought.)
Do you know of any good resources that explain more about the precise vs conservative scanning modes of Boehm?
I thought I recalled some references to a precise mode available via a "GC_MALLOC_ATOMIC" function in Boehm which would understand all of the contained data to be not-pointers and thus enable smarter handling, but perhaps that's a necessary-but-not-sufficient thing on the road to heap compacting. I'm hitting a lot of dead links looking for more information sadly; hpl.hp.com seems to have suffered a reorganization lately :(
We used to have instructions for installing and compiling under Linux. Since our main focus is currently iOS and some users were confused by mentioning Linux and thought that they could cross-compile for iOS on Linux we removed those instructions from the web site. Only Linux x86 can be targeted when compiling under Linux. Here's what you need to install if you are running Ubuntu 12.04:
[edit: are you saying only 32-bit Linux can be targeted, and not 64bit/multiarch?]
Thank you both, after looking harder at the documentation I figured out as much (except for the icu-part, I don't think that's mentioned anywhere).
Unfortunately I had to give up building under Debian 7.0 (wheezy/stable) -- even after trying with both open jdk7, oracle jdk 7 and 8, standard llvm as well as llvm 3.5 and a newer cmake (in each case the jni/llvm-bindings doesn't build, as maven fails the second test-case).
And the binary distribution is linked against a newer libc than I have.
I guess it'll be possible to get it to run in an Ubuntu VM/chroot -- but I haven't tried that yet.
For now you'll need Xcode to use RoboVM which implies Mac OS X running on Mac hardware or in a VM (it can be done although Apple doesn't allow it unless you run the VM on Mac hardware).
Thanks for pointing this out. I have now changed this to just "No interpreter involved". Except for not interpreting or JITing bytecode it's indeed very much a VM. E.g. it presents the same memory model and threading model to the running app as a desktop JVM would.
RoboVM on the other hand lets you use all the native iOS APIs from within Java and has a runtime library based on Android which limits you only to roughly the Java 6 APIs. As long as you structure your code properly RoboVM makes it possible to reuse large portions of your code between the Android and iOS versions of your app. So if you'd rather build an app that is truly native with a native UI and still want to be able to share code with Android RoboVM may be a better fit. And it's definitely not just for games even though libgdx+RoboVM is a killer combination.