I'm going to have to play with this just to see if I would like writing iOS apps in java or not. I have really gotten use to Objective-C and I really do like it, seriously. The issues with a translator is that anytime you want to fix a performance issue or tweak the translated code, you now start coding yourself into a painful place. It gets harder and harder to maintain. But, I cannot poo-poo it until I have tried. One of the reasons I jumped into iOS was to get out of java land for a while since it has been my primary source of income for 13 years. I hope to hear some other opinions on the subject.
It's not really for writing the front-end UI logic in Java, you can use MonoTouch for that. The PlayN library (code.google.com/p/playn) uses MonoTouch+IKVM to run Java code on IOS.
The goal for this is that a company like Google which has millions of lines of Java code, shared on the server, on Android, on the Web (via GWT). The best way to optimize UI is to use the native Widget set and language features since you often have to rewrite the UI for each device anyway.
However, the non-UI layers could be shared, and it is a non-trivial win. For example, products like Google Docs use Operational Transforms. We have a library that implements this in Java, and rather than maintain three separate versions (Java, JS, and Objective-C), we can keep one version of the library for three platforms.
If you consider the feature lag between Web GDrive, Android GDrive, and iOS GDrive, think about how problems of maintaining three different spreadsheet implementations and keeping them in sync. Tools like this can help.
I worked on this project at Google this summer as part of my internship (I wrote the dead code elimination phase). I think this is more useful for sharing business logic code between Android, iOS, and web (via GWT) apps without re-writes in Objective-C and JavaScript. Keep the respective presentation logic in ObjC+Interface Builder, JS+CSS, etc. I'm not sold on the idea of developing iOS apps alone in Java since the Apple tools are so good.
I've looked a bit through the documentation and noticed how exception blocks are translated to the Objective-C version (@try / @catch ...). Of course most often Objective-C coders would use NSErrors through indirection pointers in situations where Java coders would use exceptions, the use of @try / @catch is often discouraged. This is just 1 example of a possible issue, I also don't like how the namespacing is being handled (camel case name of the Java namespace). In Objective-C we're used to a 2 or 3 letter prefix. Because of issues such as these I wouldn't be very inclined to use it in my own projects.
When it comes to exceptions, its not even a matter of semantics and needing to be very clever. There are cases where exceptions in Java just don't carry over to Objective-C.
A really good example of this is NullPointerException. Objective-C lets you message null (although, its called nil in this context) without any problem.
