RoboVM - LLVM based Java ahead-of-time compiler for Mac, Linux, iOS

General Discussions
#1

http://www.robovm.org/

This looks very promising. Still early days, but the LLVM backend is a good thing as it lets one target a lot of platforms and it optimizes things quite well.

#2

Neat. Have you looked to see how they handle GC?

#3

So, mono replacement when get matured?

#4

Essentially yes. Lots of questions though. I only had a few minutes to look through the source. Seems like Soot is used to parse class files, those are then emitted as LLVM IR. No direct LLVM binding. Uses Android’s runtime libraries for better or worse, meaning all the nasty Harmony bugs are likely to be present. No idea which GC is used.

#5

Looks like Boehm: https://github.com/robovm/robovm/blob/master/vm/NOTICE.txt

#6

Bah.

Still, with careful memory management, you can use Boehm and nobody’s going to notice.

Cas :slight_smile:

#7

At least when libgdx uses it, it will be completely free framework \o/

#8

It’s a drag the vmkit seems to be stalled…they were working on using MMTk, which could have been very cool.

#9

jupp, vmkit would have been nice indeed. seems like all these solutions have the drawback of not supporting debugging :confused:

#10

Debugging is for ${stereotype-mockery} anyway.

Cas :slight_smile:

#11

Ya know, if someone out there is nuts (and my memory isn’t failing me), then MMTk is a commercial friendly license and all the real GC parts are in java (just a thin layer for raw memory accesses)…this is a potential money maker.

#12

Nice job ripping off davedes’ post 9 hours after him :stuck_out_tongue:

Anyway, this looks awesome, let’s stay optimistic about getting a free and easy road to iOS using Java!

#13

I didn’t rip anything off, i just didn’t search for a RoboVM post assuming nobody discovered it yet. I’ll pay davedes his lost… wait, what exactly did he lose?

#14

His precious thread view count and rich discussion! Nah, kidding :stuck_out_tongue:

#15

Rich dicussion. Today it seems expensive.

#16

Played around with it some more. Couple of observations:

  • uses Android’s/Harmony’s class library, so all limitations of that apply (no AWT/Swing, inferior implementation compared to Sun’s)

  • One assembly file is generated per class, with straight mappings to Java class methods etc. Looks like this:
    http://i.imgur.com/2vzbXAb.png

  • Previously compiled and unmodified classes are cached, recompilation of a project is very fast for native compilation (way faster than what i experience with MonoTouch, could just be me doing something stupid though…).

  • JNI is supported to a degree that all of our libgdx core JNI code works (haven’t tested the bullet wrapper yet though). Just needs to be compiled as a static lib and everything works out of the box. This actually worked on first try, i’m still surprised
    http://i.imgur.com/U4tCSlq.png

  • The resulting binary is pretty big at least on my test target, elf32. It’s about 12mb.

  • Loading classpath resources works, as oposed to the IKVM/MonoTouch solution

  • Debug symbols are emitted for the assembly code generated, meaning you can somewhat comfortably debug assembly. Better than nothing, e.g. what you get with Avian

  • Building binaries is very easy compared to Avian, together with the fast recompilation that’s a huge plus.

I’m gonna try write an experimental libgdx backend with this for Linux, Mac OS X and iOS. Not a fullblown one, just enough to get all the demo games somewhat running. If that works out i’ll invest time to write a proper backend.

TL;DR: looks promising, still waiting for the first crash.

#17

Ok now I’m extremely optimistic now. Good luck and thank you for all your efforts Mario!