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.
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).
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.
Yeah, I already write cross-platform code with C++ and it is really not as bad as anyone leads you to believe. Create one single C++ entry point object that drives everything else. Use sqlite for storage, jsonc for serializing/deserializing json, pthreads for threading and curl for making network requests. Your main c++ class has to also receive the events (like touch) and forward as appropriate. You can leverage STL and boost if you wish. For iOS, you end up dragging and dropping the entire project to XCode - valid C++ code is valid Objective C++. For Android, you just use the ndk to create a simple Java class that mirrors your entry point C++ class and the implementation is just JNI calls to the C++ class. It is common to have a secondary "utilities" class that does hardware specific things if you wish. Your GuI is quickly put together using the standard OS tools - but as long as you stick to forwarding the work to the main C++ class, all that GUI code tends to be minimal (except for really fancy platform specefic GuI code like transitions). Oh, and I use OpenGL for drawing most cool things, so I get to reuse that, too - not to mention all my code is really fast. There you go - cross platform iOS / Android / Mac / Linux / Windows development.
Toss in lua(jit) and you have a nice dev environment. I wrote a lua->java bridge and modified LTC (lua tiny cocoa, a lua objective c bridge) and with those you can write nearly your entire cross-platform app (ui, too) in C / Lua.
And with luajit's FFI support, it's almost a better C than C.
I've tried using the NDK too, specifically to compile the Objective C framework ObjFW [1] on one of the few platforms where it's not yet confirmed working. Unfortunately, the gcc they include in the NDK has Objective C disabled for seemingly no reason, and bootstrapping your own gcc or clang toolchain is pretty tough. I'm sure you don't see as much of a need with C++, but have you ever tried replacing parts of the toolchain?
There you go - cross platform iOS / Android / Mac / Linux / Windows development.
The only thing missing is...the browser.
We're doing the same thing, but with JavaScript as the application code, and unique front-ends for HTML5 browsers, older browsers, Android, iOS, mobile browsers, etc.
It's trivial to get a JavaScript VM running on any given platform.
I love this quote from the article.
"Several Google projects rely on [J2ObjC], but when new projects first start working with it, they usually find new bugs to be fixed,"
And also
"If you'd like to join the bug hunt, the full source code for J2ObjC is available now under the Apache open source license"
I'm not opposed to bridge software; however, I'm always skeptical when I hear things like this.
"Google says J2ObjC works with most build tools, including Xcode and Make, and that the translation from Java to Objective-C is totally automated. No additional editing of the Objective-C source code output by the tool is necessary."
The proof is in the pudding. I guess I'll have to check it out.
Technically cute, but works only for non-UI modules, which comprise approximately 4% of a mobile app.
Anything with a large backend is likely an intensive game, and aren't those cores written in native C/C++ anyway?.
Someone please take an app in Objective C, convert it to JS with route 66, convert to Java with (?) And convert back to Obj C with this tool, and share.
There are a lot more Java libraries than Objective-C libraries. Especially at Google.
We write a lot of Java at Google, but I wouldn't call anyone a "Java programmer". We're just programmers. And like all programmers, if we can save time by writing a tool and letting the computer do some work, we will. Laziness, impatience, hubris, and all that.
Actually this has nothing to do with Java developers, as much as people here likes to look down on them.
This has to do with calling a single command and blasting out an app for IOS once you have already written an app for Android.
If you note carefully Google could have done it the other way around, by implementing IOS shims on top of Android.
This would have been easier (as Google controls Android) and because Objective C code is low level code that is easier to port to high level Java code.
And it would have given an incentive to those who have already written IOS apps to port them to Android.
So why not do it that way? Because then everybody would develop for IOS first and Android second and few people would use the Android specific features. By going from Android to IOS, Android is the primary system, but Google still lover the cost of development of Android apps by having the IOS market articficially subsidise it.
It is the classing Jole post (http://www.joelonsoftware.com/articles/StrategyLetterV.html) with the twist that Google is lower the price of the complements to its complements (ie. smart phones are complements to Google ads and apps are complements to smart phones).
Learning ObjC is a one-time cost I've already paid. The problem is being continually confronted with all the compromises it made against safety and readability just to rush out semi-usable implementations thirty years ago. It's no longer necessary to regress to C and risk crashes and random misbehavior from unchecked pointer arithmetic and integer overflow and uninitialized memory, and debugging that (while sometimes fascinating) has long been a poor use of hackers' time.
How so? Looks like an opportunity to have some common code between the two platforms to me. Write your view layers twice. If you have a large amount of business logic write it once in Java and then part of the build or checkout process for iOS can be to translate this code to objective-c.
I've recently been diving into mobile dev and the short list of good options on having a common code base between the platforms seems so strange to me.
[+] [-] dhconnelly|13 years ago|reply
- 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|13 years ago|reply
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).
[+] [-] RealCasually|13 years ago|reply
[+] [-] prof_hobart|13 years ago|reply
[+] [-] flatline3|13 years ago|reply
[+] [-] rburhum|13 years ago|reply
[+] [-] sshumaker|13 years ago|reply
And with luajit's FFI support, it's almost a better C than C.
[+] [-] jrajav|13 years ago|reply
[1] https://webkeks.org/objfw/
[+] [-] kvnn|13 years ago|reply
Do you have any code you can share? Are there any resources in general I should check out?
[+] [-] erichocean|13 years ago|reply
The only thing missing is...the browser.
We're doing the same thing, but with JavaScript as the application code, and unique front-ends for HTML5 browsers, older browsers, Android, iOS, mobile browsers, etc.
It's trivial to get a JavaScript VM running on any given platform.
[+] [-] chj|13 years ago|reply
[+] [-] mrwilliamchang|13 years ago|reply
And also "If you'd like to join the bug hunt, the full source code for J2ObjC is available now under the Apache open source license"
[+] [-] weej|13 years ago|reply
"Google says J2ObjC works with most build tools, including Xcode and Make, and that the translation from Java to Objective-C is totally automated. No additional editing of the Objective-C source code output by the tool is necessary."
The proof is in the pudding. I guess I'll have to check it out.
[+] [-] mitchellmckenna|13 years ago|reply
[+] [-] dhconnelly|13 years ago|reply
[+] [-] Evbn|13 years ago|reply
Anything with a large backend is likely an intensive game, and aren't those cores written in native C/C++ anyway?.
Someone please take an app in Objective C, convert it to JS with route 66, convert to Java with (?) And convert back to Obj C with this tool, and share.
[+] [-] flatline3|13 years ago|reply
Where on earth did you get that number?
UI code in a well-structured application is a thin-shim on composed, testable backend code. It should be the least of the code, by far.
[+] [-] raverbashing|13 years ago|reply
That and the demotion of native code in Android (native code there calls Java libraries) really make me question a lot of things.
[+] [-] jrockway|13 years ago|reply
We write a lot of Java at Google, but I wouldn't call anyone a "Java programmer". We're just programmers. And like all programmers, if we can save time by writing a tool and letting the computer do some work, we will. Laziness, impatience, hubris, and all that.
[+] [-] tomjen3|13 years ago|reply
This has to do with calling a single command and blasting out an app for IOS once you have already written an app for Android.
If you note carefully Google could have done it the other way around, by implementing IOS shims on top of Android.
This would have been easier (as Google controls Android) and because Objective C code is low level code that is easier to port to high level Java code.
And it would have given an incentive to those who have already written IOS apps to port them to Android.
So why not do it that way? Because then everybody would develop for IOS first and Android second and few people would use the Android specific features. By going from Android to IOS, Android is the primary system, but Google still lover the cost of development of Android apps by having the IOS market articficially subsidise it.
It is the classing Jole post (http://www.joelonsoftware.com/articles/StrategyLetterV.html) with the twist that Google is lower the price of the complements to its complements (ie. smart phones are complements to Google ads and apps are complements to smart phones).
[+] [-] prodigal_erik|13 years ago|reply
[+] [-] stusmall|13 years ago|reply
I've recently been diving into mobile dev and the short list of good options on having a common code base between the platforms seems so strange to me.
[+] [-] watty|13 years ago|reply