J2objc - A Java to iOS Objective-C translation tool and runtime
code.google.com
code.google.com
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".
So... a garbage collector?
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.
A really good example of this is NullPointerException. Objective-C lets you message null (although, its called nil in this context) without any problem.
XMLVM also offers an Android compatibility layer, including some UI support.
I don't even...
[0] http://www.jetbrains.com/idea/features/editions_comparison_m...
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?
Note to pg: support subset of markdown for HN v2?
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.
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.
Codename One solves all of the above issues by giving "actual WORA" which is the true value of Java.
Well that seems odd... Not sure what to make of this.
There are many thousands of people inside of Google who just wish to ship great software, and enable others to do the same.