[stephenjudkins]

If you're curious how this handles memory management--the largest impedance mismatch between Java and Objective-C--see http://code.google.com/p/j2objc/wiki/MemoryManagement.

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".

[tlrobinson]

"runtime and tool support to detect memory leaks".

So... a garbage collector?

[hoka]

Well, if it's just detecting, that's not GC. That's just, "Hey! There's trash here!"

[tlrobinson]

Once you know where the trash is, the easy part is deallocating it.

[invalidname]

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.

[jonmrodriguez]

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.