News for hackers. Stuff that matters.

A comment on J2objc - A Java to iOS Objective-C translation tool and runtime.

Re:J2objc - A Java to iOS Objective-C translation tool and r... by stephenjudkins on Thursday September 13, 2012 @06:45PM (#4519054)
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".

[ Parent | on HN ]
Re:J2objc - A Java to iOS Objective-C translation tool and r... by tlrobinson on Thursday September 13, 2012 @08:22PM (#4519376)
"runtime and tool support to detect memory leaks".

So... a garbage collector?

[ Parent | on HN ]
Re:J2objc - A Java to iOS Objective-C translation tool and r... by hoka on Thursday September 13, 2012 @08:43PM (#4519466)
Well, if it's just detecting, that's not GC. That's just, "Hey! There's trash here!"
[ Parent | on HN ]
Re:J2objc - A Java to iOS Objective-C translation tool and r... by tlrobinson on Thursday September 13, 2012 @08:59PM (#4519501)
Once you know where the trash is, the easy part is deallocating it.
[ Parent | on HN ]
Re:J2objc - A Java to iOS Objective-C translation tool and r... by invalidname on Friday September 14, 2012 @08:48AM (#4521335)
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.
[ Parent | on HN ]
Re:J2objc - A Java to iOS Objective-C translation tool and r... by jonmrodriguez on Thursday September 13, 2012 @10:53PM (#4519795)
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.
[ Parent | on HN ]