J2ObjC の背後にあるモチベーション

J2ObjC は当初、機能にばらつきが出ることなくウェブとモバイルのプロダクトを迅速にイテレーションしようとして、複数の開発チームに不満を感じていました。Google のクライアント プロダクトの多くは、ウェブアプリ用の GWT（現在の J2CL）と Android モバイル デバイス用の Android API を使用して作成されています。そのため、iPod/iPad アプリは JavaScript ウェブアプリか、Objective-C で手書きする必要がありました。GWT アプリと Android アプリはビジネス ロジック（非 UI）コードを共有できますが、そのコードを iOS アプリと共有するためのソリューションはありません。

この問題を解決するためのいくつかのアプローチが調査されました。XMLVM は非常に有望なようですが、その時点で iOS トランスレータのページにはプロジェクトが停止されたと記載されていました（現在は再度アクティブになっており、このプロジェクトに代わる有効な手段です）。他の変換ツールでは、1 回限りのコード変換が行われ、出力を正常にビルドして実行するには追加の編集が必要でした。

新しいプロジェクトが始まった

当初から、多くのエンジニアは J2ObjC のような翻訳者はありえないと思っていました。すべての Java アプリケーション コードを iOS に正確に変換できると同時に、そのセマンティクスを完全に維持できるツールを作成することは不可能です。これは、iOS には厳格なユーザー インターフェース デザイン標準があり、アプリがそれに準拠していなくてもユーザーが認識しているためです。Google では、世界クラスの高速な iOS UI を実現する唯一の方法は、Apple の iOS SDK フレームワークを使用して Objective-C で記述することだと考えています。

しかし、ほとんどのエンジニアは微分計算の限界から学びましたが、不可能に近づくことは非常に有益です。そのため、J2ObjC が成功する可能性を高めるために、次のような制限を設けました。

• クライアントサイド開発のみをサポートします。理論的にはコマンドライン ツールとサーバーコードを翻訳することは可能ですが、そのユースケースには、J2ObjC で対処できない問題が含まれている可能性があります。
• ビジネス ロジック コードのみをサポートし、ユーザー インターフェース API から遠く離れます（かつて古い地図は「モンスターがいる」など）。
• 一般的なベースではなく、iOS 基盤フレームワークが必要です。
• Apple のメモリ管理のベスト プラクティスを実装した後、Xcode の Instruments を使用して、許容可能なパフォーマンスとメモリ使用量を検証します。
• 完全性の実現に必要なものではなく、アプリケーション デベロッパーが必要なものだけに注目します。プロジェクトの要件は実際のアプリケーションのニーズによって決まります。

あなたも役に立つかもしれません

J2ObjC は、iOS アプリとの Java ビジネス ロジックの共有の問題が解決されたと一部の社内プロジェクトで判明したため、オープンソース化しました。現在、いくつかのチームが翻訳ツールを利用しています。私たちは、新機能の追加や多くのバグの修正に熱心に取り組んでいます。他のモバイルアプリ チームもぜひお試しいただき、うまくいった点や改善が必要な点をお聞かせください。

また、このプロジェクトにもやりがいを感じています。Java トランスレータにとって最も難しいタスクは、1）正しい解析、型チェックと解決、2）準拠した Java ランタイム環境の提供です。最初のタスクは javac コンパイラによって適切に処理され、ランタイム環境（単体テストを含む）は Android libcore ライブラリをベースとしています。そのため、抽象構文ツリーの変更や、一般的に簡単にデバッグできるソース出力の生成といった面白さが残ります。Java のツールやコンパイラに関心をお持ちの場合は、ぜひご参加ください。やるべきことがまだたくさんあります。ぜひサポートをお願いします。