The preferred method, for iOS apps at least, seems to be use reference counting. This implies that any objects with cyclical references will not be released. Thus, the semantics of this approach will be subtly different than that all JVMs, which have GCs which can detect cyclical references. Thus, the documentation suggests using "runtime and tool support to detect memory leaks".
Its not automatic, you need to explicitly release. They are referring to the tools builtin in xcode which you will have to use manually to debug memory problems in Objective-C then move it back to your Java code as annotations.
I think that's referring to "development runtime", not "production runtime". I.e. run a memory leak detector while you are debugging and profiling. But once you fix all/most of the leaks, you don't need to deploy a GC.
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.
> In XMLVM, byte code-based programs are represented as XML documents. This allows manipulation and translation of XMLVM-based programs using advanced XML technologies such as XSLT, XQuery, and XPath.
Oh, come on. While I dislike XML as much as anyone, I can definitely see the advantages of representing an AST as XML and manipulating using a functional language (e.g. XSLT). I think the Stratego languages also do something similar, and they seemed to be quite effective last time I checked.
They have "Back to School" sale on personal licenses. I find 100 euros for an excellent IDE very cheap. It's a different story if you want something open source though.
Apparently, one can write apps in Python and the Python spec gets converted into source codes for various platforms. Looks interesting. Has anyone tried it yet?
As interesting it may ever sound, i still can't think about good use-cases for those kinds of translation tools. I have been fiddling around a bit with XMLVM (which gives really has a nice generic approach) but the point that you basically can't use any libraries leads quickly to a dead-end. Also i'm not convinced that any automatic translation of plain business-logic could compensate the sacrifice of Obj-C features.
In the early days of iOS I worked on a JavaME to C++ source translation tool. No idea if it was a commercial success or not, but it did have customers.
The main desire is for games - ones that just have a canvas or GL - so porting is easier. Also some companies want shared business logic.
It turned out to be a small market though, since iOS and Android took out the market it was easier to write twice than handle the fuss of porting.
There's no supplied GCJ for iOS. While it could be supported last time I looked GCJ had some strange assumptions around the architecture it uses.
Plus this way it's fairly simple to treat your Java as a business logic layer and code the UI in Cocoa/ObjC. Your UI is going to be device specific anyway.
It translates Java to Objective-C code without GC support (uses reference counting which you need to annotate). It doesn't define any UI so effectively you need to work on a Mac just without all the wonderful tools for UI building that apple provides and without any of the WORA you get from Java. When something doesn't work you are still stuck debugging in Objective-C. And googling stack overflow trying to understand how to translate Objective-C code to your problem.
Codename One solves all of the above issues by giving "actual WORA" which is the true value of Java.
Can't find whether it's translated from bytecode or from source file. Would be great if it's from bytecode, which means we can use tons of other languages (Clojure, Groovy, Scala, JavaScript, Python)...
You can already write code in C/C++ that works across both platforms. It's trivial to interface with objective-c, and pretty easy to call from Java using JNI.
Considering that there more iOS apps than Android out there (at least according to the AppStore), I would have exected exactly the opposite direction translator from google.
Simple - they want people to code for Android first. It's a tool to push to writing for Android then translating to iOS as cheaper than writing twice - since you can't go ObjC to Java.
The preferred method, for iOS apps at least, seems to be use reference counting. This implies that any objects with cyclical references will not be released. Thus, the semantics of this approach will be subtly different than that all JVMs, which have GCs which can detect cyclical references. Thus, the documentation suggests using "runtime and tool support to detect memory leaks".