j2obj - Translating code with Java Generic Classes

[Robert Saccone]

Hello,

I've got a Java library that I'd like to use on iOS and was in the process of learning and experimenting with j2objc.  My goal was to to translate it into a iOS framework.  However the API it exposes consists of a lot of generic java classes that consumer of the library supplies type information for.  In experimenting with a small portion of the library's source I see that the generic parameters of classes and interfaces are dropped and any place that variables of the generic type were used, the variables are now typed as just id in Objective-C.  I now know that Objective-C provides only light weight support for generics and so while I was at first surprised I understand why the j2objc translator is doing what it is doing.

 

My thinking is that my use case might not be appropriate for j2objc but before giving up I thought I would check to see if there was anything I didn't know about j2objc that I am missing or might be of help here.  I also should mention that in the end even though the library would have be translated into Objective-C the consumer(s) of it would likely have been written in Swift.  Did I miss anything or is my conclusion correct?

Thanks in advance for all comments,

Rob Saccone

[Matt Campbell]

Hi Robert,

As a user of J2ObjC for about a year now, I believe your conclusion is
correct. And there are some other things that will make translated APIs
feel foreign to an Objective-C or Swift developer, even when the Java
code is thoroughly marked up with @ObjectiveCName annotations (as mine
is). First, the JRE emulation library is not marked up with those
annotations, so if you have to deal with Java collections or other JRE
APIs from platform-specific code, those APIs will feel very foreign. Of
course, the Java collections themselves (and related things like
iterators) feel foreign in Objective-C or Swift, where one normally
works with NSArray, NSDictionary, and the equivalent Swift types. And to
avoid compiler warnings, you'll need to use JNI types like jboolean and
jint in some places, rather than the usual BOOL and NSInteger. Not sure
how that impacts Swift.

I think the ideal solution for cross-platform code would be Kotlin, with
a Kotlin to ObjC translator similar to J2ObjC. In that case, I wouldn't
want a JRE emulation library, but instead, the subset of the Kotlin
standard library that's common to Kotlin's existing JVM and JS backends.
I certainly don't have time to work on such a thing, though.

So J2ObjC is the best that we have for writing cross-platform code that
can target the Apple platforms with minimal glue and minimal runtime
overhead, using the Apple compiler toolchain so we're not likely to be
impacted by any new requirements that Apple might add in the future (as
they have in the past with 64-bit and bitcode).

Matt

[Tom Ball]

One area that may help your library is using Java nullability annotations. The Guava library team did this without major source changes by defining package-level nullability defaults, then only explicitly annotated the exceptions to those defaults (or, in some cases, refactoring the code to improve null use). When Objective C nullability annotations were added, j2objc was updated to pass them through appropriately (use either the --swift-friendly or --nullability flags). Classes and methods with nullability annotations are imported into Swift without its optional type wrapping, making their use easier to read with fewer casts required.

That said, we continue to seek community input on ways the header files j2objc generates can be improved for better Swift importing. We don't use Swift, so we depend on the kindness of strangers to help us support Swift developers better. :-)

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.