Stay organized with collections
Save and categorize content based on your preferences.
The Motivation behind J2ObjC
J2ObjC started out of frustration; the frustration several development teams
had of trying to quickly iterate their web and mobile products without them
drifting apart in functionality. Many of Google's client products were created
using GWT for web apps
(now J2CL), and the
Android API for Android mobile devices. That left iPod/iPad apps, which had to
be either JavaScript web apps, or handwritten in Objective-C. Although GWT
and Android apps could share business logic (non-UI) code, there wasn't any
solution for sharing that code with iOS apps.
Several approaches to solving this problem were investigated.
XMLVM looked very promising, but at the time its
iOS translator page stated that the project was
suspended (it's now active again, and is a good alternative to this project).
Other translation tools did one-time code conversion, requiring additional
editing before their output would successfully build and run.
A New Project is Born
From the start, many engineers thought a translator like J2ObjC wasn't
possible. Creating a tool that can accurately translate all Java application
code to iOS while perfectly preserving its semantics is indeed impossible!
That's because iOS has rigorous user interface design standards, and its users
are very aware when an app doesn't adhere to them. In our opinion, the only
way to get a world-class, fast iOS UI is to write it in Objective-C using
Apple's iOS SDK frameworks.
As most engineers learned from limits in differential calculus, however, it
can be very useful to just get close to the impossible. We therefore set out
with a set of limits that would improve the chances of J2ObjC succeeding:
- Only support client-side development. Command-line tools and server code in
theory could be translated, but that use case is likely to have problems not
addressed by J2ObjC.
- Only support business logic code, and stay far, far
away from user interface APIs (as the old maps used to have in their outlying
corners, "here there be monsters").
- Require the iOS Foundation
Framework,
not a more general base.
- Use Xcode's
Instruments
to verify acceptable performance and memory use, after implementing Apple's
best practices for memory management.
- Only focus on what's needed by the
application developers, rather than what is needed for completeness. Real
applications' needs drive project requirements.
We Find It Useful, Maybe You Will, Too
We open-sourced J2ObjC as some internal projects were finding it solves the
problem of sharing Java business logic with their iOS apps. Several teams
rely on the translator now, and we're busily adding
new functionality and fixing lots of bugs. We welcome other mobile app teams
to give it a try, and let us know what works and what needs improving.
We also find working on the project rewarding. The two hardest tasks for any
Java translator are 1) correctly parsing, type checking and resolving Java
source, and 2) providing a compliant Java runtime environment. The first task is
handled well by the javac compiler, and
the runtime environment (including its unit tests) is based on the
Android libcore library.
That leaves the fun stuff for us: mutating abstract syntax trees and generating
generally easy to debug source output. If you have an interest in Java tools or
compilers, join us! There's still lots to do, and we would love the help.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2024-07-10 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-07-10 UTC."],[[["\u003cp\u003eJ2ObjC enables sharing business logic (non-UI) code between Java/Android and iOS applications, avoiding code duplication and drift.\u003c/p\u003e\n"],["\u003cp\u003eIt focuses on translating client-side business logic, excluding UI code, to Objective-C for integration into iOS projects.\u003c/p\u003e\n"],["\u003cp\u003eThe project leverages existing tools like the javac compiler and the Android libcore library, simplifying development and ensuring quality.\u003c/p\u003e\n"],["\u003cp\u003eJ2ObjC is actively used by Google's internal teams and open-sourced for broader community use and contributions.\u003c/p\u003e\n"],["\u003cp\u003eThe project prioritizes practical application needs, addressing real-world challenges faced by mobile app developers.\u003c/p\u003e\n"]]],[],null,["The Motivation behind J2ObjC\n----------------------------\n\nJ2ObjC started out of frustration; the frustration several development teams\nhad of trying to quickly iterate their web and mobile products without them\ndrifting apart in functionality. Many of Google's client products were created\nusing [GWT](https://developers.google.com/web-toolkit/) for web apps\n(now [J2CL](https://github.com/google/j2cl)), and the\nAndroid API for Android mobile devices. That left iPod/iPad apps, which had to\nbe either JavaScript web apps, or handwritten in Objective-C. Although GWT\nand Android apps could share business logic (non-UI) code, there wasn't any\nsolution for sharing that code with iOS apps.\n\nSeveral approaches to solving this problem were investigated.\n[XMLVM](http://xmlvm.org/overview/) looked very promising, but at the time its\n[iOS translator](http://xmlvm.org/iphone/) page stated that the project was\nsuspended (it's now active again, and is a good alternative to this project).\nOther translation tools did one-time code conversion, requiring additional\nediting before their output would successfully build and run.\n\nA New Project is Born\n---------------------\n\nFrom the start, many engineers thought a translator like J2ObjC wasn't\npossible. Creating a tool that can accurately translate all Java application\ncode to iOS while perfectly preserving its semantics is indeed impossible!\nThat's because iOS has rigorous user interface design standards, and its users\nare very aware when an app doesn't adhere to them. In our opinion, the only\nway to get a world-class, fast iOS UI is to write it in Objective-C using\nApple's iOS SDK frameworks.\n\nAs most engineers learned from limits in differential calculus, however, it\ncan be very useful to just get close to the impossible. We therefore set out\nwith a set of limits that would improve the chances of J2ObjC succeeding:\n\n- Only support client-side development. Command-line tools and server code in theory could be translated, but that use case is likely to have problems not addressed by J2ObjC.\n- Only support business logic code, and stay far, far away from user interface APIs (as the old maps used to have in their outlying corners, \"here there be monsters\").\n- Require the [iOS Foundation\n Framework](http://developer.apple.com/library/ios/#DOCUMENTATION/Miscellaneous/Conceptual/iPhoneOSTechOverview/CoreServicesLayer/CoreServicesLayer.html#//apple_ref/doc/uid/TP40007898-CH10-SW19), not a more general base.\n- Use [Xcode's\n Instruments](https://developer.apple.com/library/mac/#documentation/developertools/conceptual/InstrumentsUserGuide/Introduction/Introduction.html) to verify acceptable performance and memory use, after implementing Apple's best practices for memory management.\n- Only focus on what's needed by the application developers, rather than what is needed for completeness. Real applications' needs drive project requirements.\n\nWe Find It Useful, Maybe You Will, Too\n--------------------------------------\n\nWe open-sourced J2ObjC as some internal projects were finding it solves the\nproblem of sharing Java business logic with their iOS apps. Several teams\nrely on the translator now, and we're busily adding\nnew functionality and fixing lots of bugs. We welcome other mobile app teams\nto give it a try, and let us know what works and what needs improving.\n\nWe also find working on the project rewarding. The two hardest tasks for any\nJava translator are 1) correctly parsing, type checking and resolving Java\nsource, and 2) providing a compliant Java runtime environment. The first task is\nhandled well by the [javac compiler](https://openjdk.org/groups/compiler/), and\nthe runtime environment (including its unit tests) is based on the\n[Android libcore library](https://android.googlesource.com/platform/libcore/).\nThat leaves the fun stuff for us: mutating abstract syntax trees and generating\ngenerally easy to debug source output. If you have an interest in Java tools or\ncompilers, join us! There's still lots to do, and we would love the help."]]
