J2ObjC 幕後的動力

J2ObjC 一開始出於失望；許多開發團隊試圖快速疊代網路與行動產品，卻將功能與功能合併，因而感到失望。許多 Google 用戶端產品都是使用適用於網頁應用程式的 GWT (現為 J2CL) 和 Android 行動裝置的 Android API 所建立。然後離開 iPod/iPad 應用程式 (必須設為 JavaScript 網頁應用程式) 或在 Objective-C 中手寫。雖然 GWT 和 Android 應用程式可以共用商業邏輯 (非 UI) 程式碼，但與 iOS 應用程式共用該程式碼沒有任何解決方法。

並調查了幾種可以解決這個問題的方法。XMLVM 前景看來很不錯，但在「iOS 翻譯工具」頁面表示專案已遭停權 (現已再次啟用，現為該專案的絕佳替代選項)。其他翻譯工具只會進行一次性程式碼轉換，他們需要進行額外的編輯才能成功建構及執行輸出內容。

新專案的誕生

就一開始，許多工程師都認為 J2ObjC 這樣的翻譯不是可能的。建立能將所有 Java 應用程式程式碼準確轉譯為 iOS 的工具，同時完美保留語意，實在是不可能的！這是因為 iOS 設有嚴格的使用者介面設計標準，而且使用者非常瞭解應用程式是否遵循這些標準。如我們看來，要取得世界級的快速 iOS UI，唯一方式就是使用 Apple 的 iOS SDK 架構，在 Objective-C 中編寫 UI。

不過，由於大多數的工程師都從差異微積分的極限學習，因此如果能接近不可能的任務，就很有用。因此，我們設定了一組限制，以改善 J2ObjC 成功的機率：

• 僅支援用戶端開發。理論上，指令列工具和伺服器程式碼可以轉譯，但這類用途可能還有 J2ObjC 無法解決的問題。
• 僅支援商業邏輯程式碼，且遠離使用者介面 API (就像過去位於外邊角落的舊地圖，「在這裡有怪物」)。
• 需要使用 iOS 基礎架構，而非較為籠統的基礎。
• 實作 Apple 的記憶體管理最佳做法後，請使用 Xcode 的檢測工具驗證可接受的效能和記憶體用量。
• 請只關注應用程式開發人員所需的需求，而非完成完整程序所需的項目。實際應用程式的需求驅動專案需求。

我們找到實用、或許您也會有幫助

我們開放 J2ObjC 的原始碼做為一些內部專案，因為一些內部專案可以解決與 iOS 應用程式共用 Java 商業邏輯的問題。現在，我們有幾團隊負責翻譯，而且我們也正在努力新增功能並修正許多錯誤。歡迎其他行動應用程式團隊試用，告訴我們哪些做法有效、哪些需要改善。

此外，我們也發現許多公司都在努力展開這個專案。所有 Java 翻譯工具最困難的兩項工作是 1) 正確剖析、檢查類型及解析 Java 來源，以及 2) 提供符合規定的 Java 執行階段環境。javac 編譯器妥善處理第一項工作，執行階段環境 (包括其單元測試) 是以 Android libcore 程式庫為基礎。這會保留我們的樂趣：變更抽象語法樹狀結構，並產生通常容易對原始碼輸出進行偵錯。如果您對 Java 工具或編譯器有興趣，歡迎加入我們！行動仍有許多工作尚待完成，我們非常樂意提供協助。