I used this tool 2-3 years ago (back when it was still hosted on Google Code!). It does what it says on the box (converts code from Java to Obj-C) - the problem is all about expectations.
In a way, this being an "official" tool from Google makes it more confusing for non-technical folks. When you read that Google has released a tool for converting Java to Obj-C, many assume it's now trivial to get an Android app converted to iOS. This tool will not translate an Android app into iOS code. It won't really even help that much unless you've made a deliberate effort to isolate code so that a conversion could happen. Most of the time, the business logic for mobile apps is fairly simple so you aren't saving much time.
In my experience, the difficulty in shipping cross platform mobile apps is dealing with platform specific conventions (e.g. what is the iOS equivalent of a Fragment?) and libraries (RestKit on iOS, Retrofit on Android, etc); not the conversion of basic Java class into their Obj-C equivalents.
Well, it does say so on the main page :) .
I suspect that this warning is here so that devs can show it to the eager product managers ...
I am still not that convinced by this approach either though.
Sure, that way you are sure that all your apps handle the business logic in the same way but since the platforms are so different, the cost of extracting the business logic can be pretty high for a low return.
While I appreciate the tecnological background of this project, I don't like this kind of traslators.
It could be useful if you need to execute Java code in Objective-c runtime, but not if you want develop iPhone/iPad app.
Obj-C is simple, the problems are the iOS frameworks that you need to learn to delivery an iOS App.
If you are Java skilled, anyway you need to learn these frameworks, and you will spend your time to traslate the examples(stackoverflow) from obj-c to java
I'm not a xcode fans, but it is a great tool when you use the StoryBoard and all features to test, performance, memory .. etc.
Another point is that with the introduction of the Swift language this traslator loses other value
The purpose of j2objc is not to address a single platform. It's not to write code in Java in order to deliver an iOS only app. It's to share logic across multiple platforms.
If you combine j2objc and GWT together, you can share code between Web, native Android, and native iOS, while writing the UI in JS, Objective-C with InterfaceBuilder/Xcode, or native Android Views.
If you want to share non-UI code across all three platforms you have these kinds of choices:
* js everywhere (WebView wrapper or embedded JS interpreter on iOS)
* C everywhere (emscripten/NaCl on WEB)
* Java everywhere (GWT->js for Web, j2objc for iOS)
I can only speak from experience, but option three worked fantastically.
I've often heard this idea about 'sharing logic across multiple platforms'.
I agree that it's a noble goal, but I'm curious about places where that sort of logic is actually common enough to justify the overhead of maintaining a cross-platform library.
Most of the applications on my phone are ultimately native UI skins over web services. There might be some logic in there to handle other features, but in most cases it's tied into OS-native features anyway.
I can see cross-platform libraries being useful for games using GL, maybe for media applications that require formats not supported by the OS, and for applications that do heavy image or audio processing – in short, the sort of thing where the value-add is specifically high-performance processing. Maybe that's enough to justify the existence of these tools, though I'd imagine it's almost always a better option to write your library in C in the first place.
I think you're underestimating the amount of platform-independent code in a typical app.
Looking though a random sample of non-game apps on my iPad, I'd guess that about half would have a significant chunk of code which is not OS-specific, including: Gmail, Spotify, Anki, Google Maps, Facebook, Twitter, Penultimate.
I also don't think that the choice between C and Java as the common language is so clear cut. C would get you some speed benefit but Java has GWT for porting Java to Javascript, and and a huge range of other tools and libraries. In the end I think it would come down to how comfortable your development team was in each language.
> a fairly sophisticated client side application
is it actually an full blown IMAP client? Most likely it uses AJAX to fetch JSON from Google's proprietary APIs
It works offline, that should give you a clue that it is not just a request/response app. Yes, it does make requests to Google's servers, but it can run completely offline with no connection as well.
A lot of apps are just API consumers, but apps with any kind of moderately advanced functionality will require some kind of entity model and business rules that need to be captured. Having those things go out of sync between platforms can be a source of bugs or slower development. For shops invested in Java or with a lot of Java engineers, something like this can be be useful so that the entity model and business rules can be encapsulated in a single code base.
From my experience with servers-side JS code, if your JS is fast enough to run with every server request, it's also fast enough to run on today's mobile processors. Obviously for Client-side code this isn't true, but then again if you want your apps accessible from mobile browsers, you need to have it reasonably optimized anyway.
Yeah you just need to know C, possibly C++, and smalltalk and be comfortable using the syntaxes for all three simultaneously. For the record though I'm a big fan of C and C++, and I don't really care for Java. I can just see why people who already know Java well would want to use Obj-C as little as possible.
In a web/js/Ruby/mobile echochamber that may be true. But in the real world C/C++ is very far from being a minority skillset. Take a look at [1][2][3]. C, C++, and Java are the main languages in use today.
You need look at the growing data.
Maybe the number of people that know c or c++ are more for the ages of the languages itself.
Try to look any statistics about github[1] [2]
The bulk of Java/C/C++ source will never see the light of day as they power systems owned by corporations who see them as an asset.
Looking at public repos for stats is like counting the number of tables on planet earth by looking at satellite photos. You never see inside the buildings, just whats outside in parks etc.
Let's take a brief moment to talk about systems software, and infrastructure.
It powers your OS, your VM instance running your flashy new CRUD app, your network protocols, your game engines, your browser, the interpreter or compiler you use to run your high level languages, and much, much more.
Programs such as these need high performance, low level access to hardware, or the ability to manage resources in a custom way. Languages like C, and C++ are very well suited for this. Sure, I wouldn't write a web-app in C++, but then again, I wouldn't write a javascript jit-compiler in javascript (okay maybe in asm.js for kicks).
Personally, when I see the growth of higher-level languages like these, I don't attribute it to the fall of low-level languages, but instead to the availability of new languages good for certain tasks.
In 2014, we have the luxury of being able to write applications at higher levels of abstraction, and this is a good thing. But tools like C, and C++ are still, and will be widely used by anybody who needs to develop something with requirements such as those I have mentioned. Layers of abstraction need to be built on top of something, and that something needs to work efficiently and quickly.
I'm using RoboVM for production apps, which uses LLVM and the Android runtime to compile Java into native iOS apps. Also binds easily to Objective-C frameworks (and the libGDX game framework).
We've been working on Inbox for years, and RoboVM didn't exist when we started. I'm sure if it was as polished as it is now, we might have considered it.
I get it - Java people want to work in Java. However, this tool seems only targeted at the M in the MVC paradigm. You still need to write your views and controllers in Objective-C. Unless your app has a large number of very complex model objects, it's probably quicker to just retype your model classes in Objective-C. Of course if your app does have a lot of very complex model objects (as Google probably does) and you want to always have them in sync across platforms without having to retype anything then this makes a ton of sense. But for the majority of apps, it does not.
Just wanting to share a similar use case for such a project:
Used to work at a company where they were developing mobile games for 50+ different mobile phones, back when there was still more diversity in the market, just when iPhone was still rising to take over the markets.
The method they used at that time for developing their games was to write the project once with Java, then convert with an inhouse build tool to Objective-C++ when targetting iPhone. They even had builtin carbage collection and everything in the converter runtime, it seemed crazy that they would go to such trouble.
But they were releasing about 50+ games a year, a pretty big company, so I guess it paid back in writing the project once and porting to multiple platforms.
Took maybe 25 minutes to compile the whole thing, first from Java to Objective-C++ and then compiling that whole mess of a project in Xcode. It kinda worked, but the performance it produced on the iPhone was far from optimal. Debugging was also horrible.
Sounds like the XMLVM hack which basically transplate Java bytecode into a stack machine emulator in C++ by using bytecode->XML and then XSLT stylesheets -> C++. As expected, this is slow. This is not what j2objc does, and j2objc doesn't try to emulate garbage collection either, instead it generates ARC compatible code, and you use @Weak annotations in Java to fix cycles.
Edit: Furthermore, you expect me to carefully read the source of every single third-party library I use and patch it to break any potential cycles? This is madness!
Really nice tool. I haven't tried it on any non-trivial code yet but it worked well for a couple of small utility functions I use all the time. I know Java and I'm an ObjC learner, but I have to get some stuff working quickly and this might help short cut the process. I only worry that it will be a crutch to keep me from learning ObjC well.
Sounds good but suppose I need to make a network request on iOS. How would that work since there is no common Java library to do it on iOS as well as Android?
If we're only going to write the very limited business logic in Java I don't really see the benefit.
No, but did it also use java translation? That would involve writing wrappers for many of the native libraries. They would also have to do View/Controllers in objective-c (or some equivalent translator). And finally, they would have to special-case operating systems everywhere. This framework would not at all suffice to do multi-platform development; xamarin, robovm, cordova, and titanium all get much closer to this goal.
Would be interesting to compare performance/memory footprint of native Android app, and that same app after going through Java -> j2objc -> apportable -> Android...
The roundtrip version might be faster in some cases because it's not Java anymore, but native code. AFAIK, Apportable uses GNUStep libraries and the Android NDK, so the translated version would be an ARM binary on Android.
Of course you can't do that for a real app because they use the Android APIs, not just the foundation libraries supported by j2objc.
The tooling for this and gwt are impressive and no doubt useful to the teams at google managing cross platform code.
Just unfortunate that the starting point is Java source code (note: not bytecode, you can't use clojure or other jvm platform langs) - I just have no interest in coding in java when there are so many other better languages available all across the spectrum.
RoboVM, an alternative to j2obc already mentioned in a sibling comment, DOES consume bytecode. You might wanna check that out :)
I'll personally vouch for it's capacity to handle non-java; I've even gone so far as to feed it weird bytecode crafted from a personal fork of Apache JavaFlow... and it handled it 100% correctly, first try.
In a way, this being an "official" tool from Google makes it more confusing for non-technical folks. When you read that Google has released a tool for converting Java to Obj-C, many assume it's now trivial to get an Android app converted to iOS. This tool will not translate an Android app into iOS code. It won't really even help that much unless you've made a deliberate effort to isolate code so that a conversion could happen. Most of the time, the business logic for mobile apps is fairly simple so you aren't saving much time.
In my experience, the difficulty in shipping cross platform mobile apps is dealing with platform specific conventions (e.g. what is the iOS equivalent of a Fragment?) and libraries (RestKit on iOS, Retrofit on Android, etc); not the conversion of basic Java class into their Obj-C equivalents.