ntherning

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.

/Niklas

[0] http://www.mono-project.com/Working_With_SGen

Just to add some more info:

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:

  sudo apt-get install build-essential g++-multilib openjdk-7-jdk

  sudo mkdir -p /usr/share/icu
  sudo sh -c 'curl "http://download.robovm.org/icudt48l.dat" > /usr/share/icu/icudt48l.dat'

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.