4 ms·

I worked on this project this summer at Google, and I've been cracking up at the news coverage and HN/Reddit comment threads for a couple of days now. Here's wh

I worked on this project this summer at Google, and I've been cracking up at the news coverage and HN/Reddit comment threads for a couple of days now. Here's why: - People love to spout off about why Google does this or that. I guarantee you that the goal of this project is NOT to help "lazy developers" avoid learning Objective-C. Effective use of J2ObjC requires you to use Objective-C and Xcode. - Many developers seem to think that application architectures from their particular domains of expertise are universal or most important. There are many apps for which "core business logic", and not UI code, dominates. - Small-team/single-platform/large-team/multi-platform developers seem to have trouble imagining what it's like to be on the other side. - Reading non-technical articles about a technical project that you've worked on is bizarre.

saurik 14y ago
Yeah... I developed a bridge (not a native compiler) from Java to Objective-C for the iPhone (called JocStrap: Java/Objective-C bootstrap, for use with the JamVM, which I also ported) back when the device first came out, and I had a ton of people who would contact me because they thought it would make it so they didn't have to learn Objective-C, or that that would be the only reason to want it... I then had to keep explaining to these developers that "in fact, to use this kind of bridge, you will need to be both an expert at Objective-C and an expert in Java, or you will likely run into some horrible semantic mismatch between how your code at the boundary operates and what the two runtimes each require"; it seems like the same is true of your J2ObjC (especially with regards to memory management).
prof_hobart 14y ago
My guess would be that the goal was to encourage cross-platform developers to work on the Android version first. Am I close?
- georgemcbay 14y ago
  I would guess at least part of the goal would be to minimize dependence on the NDK for cross-platform "business logic". One of the more common ways to share code between Android and iOS now is to have a library written in C/C++ which is linked via NDK on Android and wrapped in ObjC/ObjC++ on iOS. In an all plain-ARM world this is no big deal, but the more CPU types you add the more of a pain this becomes on the Android side despite some support in the SDK for "fat binaries" (you still have to anticipate and compile for all those arches, whereas Java/Dalvik code will "just work" regardless of underlying CPU). Given Intel's recent push into Android along with the continued divergence of ARM into lots of branches with different features, different SIMD instructions, etc, this seems like a pretty useful solution to that problem. Either way, this was a Summer of Code project. I doubt Google gave a ton of thought to how it fits into their overall global strategy for Android development as many bloggers seem to be theorizing about.
  - dhconnelly 14y ago
    This was not a summer of code project. It was sponsored by several major Google projects with multiple contributors from their teams. I worked on the project as an intern.
RealCasually 14y ago
Thanks for posting here. How does this project relate to XMLVM (from Google employees)? We used that in order to bridge an Android app to iOS and found it to be pretty impressive. Is this based on that foundation, or a purely new effort? The main difference I see from XMLVM is that it tried to also bridge some aspects of UI, as well as was a bit more generic to attempt to bridge to C and C# as well.
- dhconnelly 14y ago
  This is a new effort. The tool produces Objective-C output that is "reasonably" close to what a human might write, so that the sources can be more easily integrated with other Objective-C code in an iOS app and debugged, whereas XMLVM output looks like bytecode.
flatline3 14y ago
How are you handling translation of exceptions to ObjC given that none of the OS frameworks are themselves exception-safe?
- dhconnelly 14y ago
  Right now it's just using Objective-C exceptions. Your iOS code that calls into the J2ObjC-translated Java code will have to handle the exceptions.
  - flatline3 14y ago
    Does j2objc ensure that internal exceptions never bubble through framework stack frames? Also, I believe arc itself is not exception-safe.

saurik 14y ago

Yeah... I developed a bridge (not a native compiler) from Java to Objective-C for the iPhone (called JocStrap: Java/Objective-C bootstrap, for use with the JamVM, which I also ported) back when the device first came out, and I had a ton of people who would contact me because they thought it would make it so they didn't have to learn Objective-C, or that that would be the only reason to want it... I then had to keep explaining to these developers that "in fact, to use this kind of bridge, you will need to be both an expert at Objective-C and an expert in Java, or you will likely run into some horrible semantic mismatch between how your code at the boundary operates and what the two runtimes each require"; it seems like the same is true of your J2ObjC (especially with regards to memory management).

prof_hobart 14y ago

My guess would be that the goal was to encourage cross-platform developers to work on the Android version first. Am I close?

georgemcbay 14y ago
I would guess at least part of the goal would be to minimize dependence on the NDK for cross-platform "business logic". One of the more common ways to share code between Android and iOS now is to have a library written in C/C++ which is linked via NDK on Android and wrapped in ObjC/ObjC++ on iOS. In an all plain-ARM world this is no big deal, but the more CPU types you add the more of a pain this becomes on the Android side despite some support in the SDK for "fat binaries" (you still have to anticipate and compile for all those arches, whereas Java/Dalvik code will "just work" regardless of underlying CPU). Given Intel's recent push into Android along with the continued divergence of ARM into lots of branches with different features, different SIMD instructions, etc, this seems like a pretty useful solution to that problem. Either way, this was a Summer of Code project. I doubt Google gave a ton of thought to how it fits into their overall global strategy for Android development as many bloggers seem to be theorizing about.
- dhconnelly 14y ago
  This was not a summer of code project. It was sponsored by several major Google projects with multiple contributors from their teams. I worked on the project as an intern.

RealCasually 14y ago

Thanks for posting here. How does this project relate to XMLVM (from Google employees)? We used that in order to bridge an Android app to iOS and found it to be pretty impressive. Is this based on that foundation, or a purely new effort? The main difference I see from XMLVM is that it tried to also bridge some aspects of UI, as well as was a bit more generic to attempt to bridge to C and C# as well.

dhconnelly 14y ago
This is a new effort. The tool produces Objective-C output that is "reasonably" close to what a human might write, so that the sources can be more easily integrated with other Objective-C code in an iOS app and debugged, whereas XMLVM output looks like bytecode.

flatline3 14y ago

How are you handling translation of exceptions to ObjC given that none of the OS frameworks are themselves exception-safe?

dhconnelly 14y ago
Right now it's just using Objective-C exceptions. Your iOS code that calls into the J2ObjC-translated Java code will have to handle the exceptions.
- flatline3 14y ago
  Does j2objc ensure that internal exceptions never bubble through framework stack frames? Also, I believe arc itself is not exception-safe.