0

I'm using J2ObjC for a project. I did setup everything and included my Java classes.

Only note is that I had to disable ARC because otherwise my Java codebase would not transpile/compile. (J2ObjC itself is recommended with arc disabled)

Since I wasn't able to disable for generated files only, I disabled it from Objective-C in Project Inspector -> Target -> Build Settings -> Apple LLVM 8.0 - Language - Objective C -> Objective-C Automatic Reference Counting (No)

Then I created my ViewController in Swift, and instantiated with no problems classes transpiled from Java (headers of generated .h files included in bridging header), and I have not to do any dealloc/release I should have to do in a Obj-C VC with no ARC.

Is this normal/leak-safe? By leak-safe that I mean that if I instantiate a transpiled class object, after the reference count decreases, it gets deallocated automatically as ARC-usual (I know ARC can't be disabled in Swift).

I know that I still have to watch out for reference cycles in Java classes but that's not what I meant by leak-safe.

BlackBox
  • 631
  • 1
  • 5
  • 19
  • Maybe I don't understand, but if you turned it off ARC in the project to compile the ported code, then it won't have ARC. You'll have to explicitly release anything that isn't autoreleased. Why not compile only the ported code with `-fno-objc-arc`? – danh Jan 03 '17 at 16:35
  • I tried to bit I could not do it because the files that should be non-ARC are generated by j2objc during the build and are not appearing in Build Phases, while the Java ones are, and the command makes no effect on them. Yeah I disabled ARC in the project but since Swift is ARC by default and not changable I was wondering if it still applies since compiler gives no warnings or errors. – BlackBox Jan 03 '17 at 16:43
  • The objective-C tag threw me off. – danh Jan 03 '17 at 16:45

1 Answers1

0

Why did you have to disable ARC? j2objc-generated code should work either with or without ARC (details here). We recommend not using ARC because it performs slightly slower for generated code, but with either memory model the code should correctly manage its memory.

As for leak-free, that can depend on the Java code, which can have reference cycles that aren't an issue with garbage collection. J2ObjC's cycle_finder can find many of these cycles, and running Xcode Instruments Leaks tool can find any others.

tball
  • 1,984
  • 11
  • 21