7 ms·
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/Memo
by stephenjudkins 14y ago
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 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 14y ago"runtime and tool support to detect memory leaks". So... a garbage collector?
- hoka 14y agoWell, if it's just detecting, that's not GC. That's just, "Hey! There's trash here!"
- tlrobinson 14y agoOnce you know where the trash is, the easy part is deallocating it.
- invalidname 14y agoIts 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 14y agoI 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.