J2ObjC is a command-line tool that translates Java to Objective-C
developers.google.com
developers.google.com
I was amazed that we were able to pull it off, tbh. The biggest issue that I remember was that the Java collection classes didn’t transpile well to JS. So we made an abstraction over them. Java code used the native collection classes, JS code used native JS arrays, etc.
For iPhone, which they arrived late to the party, the code was compiled with an tool built inhouse that converted the Java code to Objective-C++, with homemade garbage collection code. The end results were impressive from a standpoint of having the ability to target 50+ different devices at the time (when you still had J2ME phones on the market) but the performance was just not there for the iPhone, the games ran pretty poorly on that platform and ultimately I think that is one of the reasons they went bankrupt.
Still, the tech was quite fascinating, very difficult to debug and slow to compile. First you had to run the whole project through the Java -> Objective-C++ converter which took quite some time, and then you had to compile this huge Xcode project, in total I think it could take easily like 30-40 minutes just to get build. Debugging was a pain in the ass also, the code generated was not easy to read or very concise.
Wondering if they maybe used this tool ? When was this project started, any idea ?
With android apps being written in Java, Google (and anyone actually) can share code between the web, android and ios at the same time. I’m no google employee, but from what I’ve read they do use this to share the difficult logic of google drive apps between all platforms, while letting the platform-native frontend do the rest.
Oh that's sure an interesting project. A shame it apparently requires the use of Bazel as the build system. I wish I could just add it as a module to my existing Maven project and rewrite my frontend code from TypeScript to Java — but that's Google, and Google can never stop inventing their own ways of building things.
edit: I might try https://github.com/Vertispan/j2clmavenplugin
It's a pity Google doesn't anymore see value in external input/testing for j2cl and closure-compiler since these are decent projects.
It is really fast, but slightly different than J2CL.
Aside from the github repo, most of the conversation as we work on this happens at https://gitter.im/vertispan/j2cl - feel free to stop by to ask any questions or share a use case that seems under-represented.
Weird statement by the company who created flutter.
The thinking was that having portable widgets was not a good thing and for the highest quality app you still want native UI, while having portable "model" [ as in model in model view controller ] code.
Flutter was developed by a different team, and has a different philosophy about this - and in part this is driven by solving for a different goal. For super sophisticated complex apps with large teams, native is still the way to go. If you look at all of Google's own major apps, they are all native.
The majority of their revenue by way of ads is handled via AngularDart in the web interface and Flutter on mobile devices.
They literally put billions of dollars of mission critical stuff into Flutter at this point. Same with the entire Google Pay ecosystem and soon to be with Fuschia.
I don’t think Flutter is a great tool for a bunch of use cases but that list is shrinking a lot with each release. It certainly has all the moving parts needed in terms of technical capabilities to investment to make it a default choice for a lot of things in the future.
You still have to staff up your platform teams, though, and now you have the cross-language barrier to deal with in each code base, so each team needs expertise in that as well.
Flutter lets you have just one team write one app, maybe with different themes per platform, but it's still all in the same language and runtime. The cost being that you get not-quite-native UI and performance, but maybe that's an OK trade-off.
The other cross-platform alternatives are C++ (potentially faster but unsafe by default with footguns galore) and JavaScript (incredibly slow - have to RPC everything into a webview).
Rust might also be a good fit for something like this, but I'm not sure what the story is for compiling Rust for Android JNI or with Objective-C/Swift.
[0] There was this grand idea to make Objective-C the language for mobile development, with an "Apportable NDK" on every platform (but iOS). It wasn't that far-fetched. The NDK was terrible at the time, and Apportable's was faster, less crashy (free couldn't call malloc in low memory situations, for instance). And then Apple released Swift. And then Google came along.