Java to Objective C cross compiler

General Discussions
#1

I’ve been thinking about doing a cross compiler using Eclipse’s JDT for some time now that would turn Java code into either Objective C or AS3, so that I could develop comfortably in Java and deploy to a platform that’s a bit more gaming friendly. Turns out it’s pretty tough, and I’m not taking on the frontal assault on language translation at the moment (maybe eventually). But I did come across a link to an interesting project that appears to be targeting iPhone development in Java. There’s a video presentation at http://www.youtube.com/watch?v=s8nMpi5-P-I&feature=related, and the project link is at http://www.xmlvm.org/.

Looks like the basic approach is to actually emulate the bytecodes directly in Objective C (or one of the other target platforms, which seem to be Python, Javascript, .NET, and C at the moment - no AS3 yet, not sure if it’s in the works or not but if Javascript is already there it shouldn’t be too tough to do), which is not ideal, since the resulting code is pretty opaque, but it does appear to work at least for the examples shown. The main problem seems to be that the Cocoa libraries need to be mocked up in Java in order to enable this to work, and that step is incomplete. This might be an area where some community interest/help could push things along a bit…

In any case, I haven’t played around with this at all yet (just pulled the source right now, haven’t even built it yet), but as I’ve been doing some iPhone dev lately and I’ve found it pretty painful, I will probably take a closer look soon. IMO it would be fantastic to be able to cross-code for both Android and iPhone all in Java by leaving your model intact and just creating platform specific views and controllers (or even better, code to model and view abstractions which you or someone else would only need to write once that would handle all this for you).

#2

Straight C would probably be even more useful.

…also… the real pain point is probably in emulating the functions of the Java libraries, and then the platform JVM’s abilities on top of that. Like threading behaviour, locking, GC, networking, file access, etc.

Cas :slight_smile:

#3

A C++ output target seems to be in there; I’m curious to see how full featured it is, as I definitely agree that output to C or C++ would be useful.

Agreed. Unfortunately this project’s approach to those issues seems to be that they need to be handled by writing Java versions of the target language’s libraries, for instance for the iPhone target there appears to be just a lot of stubs that pretend to be the most useful parts of Cocoa (which handles most of that stuff in Mac programming). There’s a bit of simulation done for testing within Java, too.

I’m assuming that during the actual cross-compilation these are linked to the real Cocoa libraries properly, but you’re absolutely right, there’s no translation of Java’s libraries or anything like that, and that’s a major productivity hit. Until I have a closer look I’m not sure exactly how constrained this makes the Java code you can write.

I just finished actually watching that video, and it looks like here’s the process in more detail:

  1. Use javac to get .class files
  2. Convert the .class files to XMLVM files (fairly simple translation, literally a dumb replacement of bytecode instructions)
  3. Apply an XLS stylesheet to these XML files - this is where all the meat is, because each stylesheet replacement directly manipulates the stack to do exactly what the JVM bytecode instruction would do if interpreted.

A simple bit of the XLS stylesheet, the part that implements iadd, looks like this:


<xsl:template match="jvm:iadd">
  <xsl:text>    _op2.i = _stack[--_sp].i;
    _op1.i = _stack[--_sp].i;
    _stack[_sp++].i = _op1.i + _op2.i;</xsl:text>
</xsl:template>

Library mappings are facilitated by using either real (if you need simulation) or phony (mocked up with the interface to trick javac into compiling) packages in your Java code - for instance, to use an NSData object under this scheme, you would import org.xmlvm.iphone.NSData in your Java project, which might merely contain stub methods to placehold the interface. Then there’s a compatibility file included in the Objective C that contains the following:


typedef NSData org_xmlvm_iphone_NSData;
@interface NSData (cat_NSData)
- (java_lang_String*) toString;
@end

Apparently the stylesheet is set up to translate org.xmlvm.iphone.NSData to org_xmlvm_iphone_NSData, so the calls to your useless Java library are mapped right onto real Objective C methods.

Apparently any Java class that’s pure bytecode can be used, too, including some built in classes (from the talk it sounds like collections are fine), you just need to translate those classes and then link up the resulting Objective C (or whatever your target is) source. I’m still unclear what happens if you call out to native libraries; probably nothing good!

So you’re absolutely right - the problem with using platform specific features is that while you can arrange access to them, you need to program to the target platform, but in the source language. There’s no magic - at least in the current version - that would translate between APIs. But it’s possible that eventually something like that could be done, since style sheet replacements are pretty flexible…it would all have to be based on a direct translation table, though. Again, this is an area where if you actually used something like this in production you’d really want to abstract that functionality into your own API, which could internally map the calls to the appropriate platform specific libraries as needed. Which is a lot of work, and sucks (no way around that, though).

Also, another problem for games is performance - even an optimizing compiler can only do so much, and emulating the JVM stack is going to be very slow (would that just about match interpreted speed? Maybe, I think…). Plus, garbage collection is through reference counting, with an auto-release pool created per-method call, which is bad, and on top of this the project seems to be under-manned and primarily academic in scope.

Due to all these issues, I’d say that something like this is probably not a silver bullet for cross deployment, since it doesn’t quite seem practical or full featured enough to really reduce the headaches. Having said that, I’m going to play around with it and do some tests, because I have quite a bit of model-only Java simulation code that should be fairly straightforward to run through this process. Perhaps a trimmed down API like Processing would be possible to set up to cross-compile with something like this. I’ll let you guys know the results, if there are any…

#4

Being just about to jump into iPhone development, I’d be interested in what you find as you dig further into this project.

#5

Just saw this video pushed on DZone. Are there any news on this stuff?

#6

I agree. For AS3 for example, the language itself is not much different to Java. The APIs are. I hope someone would take a good gaming library, like Pulpcore, and port it to different platforms.

#7

Syntactically and structurally Java to ObjC should be very easy. The only slight hitch is switching over the different methods of memory management, but that’s really not that bad. I agree that doing everything in C would probably be more useful. If you want the fastest and most easily understandable game possible on the iPhone, then you’ll basically write the View and the Input with ObjC and then do everything else in C. For having been around so long ObjC really isn’t the best at handling object allocation and management, so you’ll find that if you want to reduce overhead you will almost always opt for doing it in C, whenever possible.