J2ObjC의 동기부여

J2ObjC는 이러한 불만에서 출발했습니다. 일부 개발팀은 기능 면에서 벗어나지 않으면서 웹 및 모바일 제품을 빠르게 반복하느라 어려움을 겪었습니다. Google의 많은 클라이언트 제품은 웹 앱용 GWT(현재 J2CL)와 Android 휴대기기용 Android API를 사용하여 제작되었습니다. 그 결과 JavaScript 웹 앱이나 Objective-C로 필기한 iPod/iPad 앱이 남게 되었습니다. GWT 및 Android 앱은 비즈니스 로직 (비 UI) 코드를 공유할 수 있지만 이 코드를 iOS 앱과 공유할 솔루션은 없었습니다.

이 문제를 해결하기 위한 몇 가지 접근 방식을 조사했습니다. XMLVM은 매우 유망해 보였지만 당시 iOS 변환기 페이지에는 프로젝트가 정지되었다고 나와 있었습니다 (이제 다시 활성화된 상태이며, 이 프로젝트의 좋은 대안이 됨). 또 다른 변환 도구는 일회성 코드 변환을 수행하여 출력을 성공적으로 빌드하고 실행하기 전에 추가 수정이 필요했습니다.

새 프로젝트 탄생

처음부터 많은 엔지니어는 J2ObjC와 같은 번역기가 불가능하다고 생각했습니다. 모든 Java 애플리케이션 코드를 iOS로 정확하게 변환하면서도 시맨틱을 완벽하게 보존할 수 있는 도구를 만드는 것은 실제로 불가능합니다. iOS에는 엄격한 사용자 인터페이스 디자인 표준이 있고, 사용자가 앱이 규정을 준수하지 않을 때 이를 잘 알고 있기 때문입니다. 세계적 수준의 빠른 iOS UI를 얻을 수 있는 유일한 방법은 Apple의 iOS SDK 프레임워크를 사용하여 Objective-C로 작성하는 것입니다.

그러나 대부분의 엔지니어가 미적분학의 한계에서 배운 것처럼 불가능에 가까워지는 것이 매우 유용할 수 있습니다. 따라서 J2ObjC의 성공 가능성을 높이기 위해 다음과 같이 일련의 제한사항을 설정했습니다.

• 클라이언트 측 개발만 지원합니다. 명령줄 도구와 서버 코드를 이론적으로 변환할 수 있지만 이러한 사용 사례에서는 J2ObjC로 해결되지 않는 문제가 있을 수 있습니다.
• 비즈니스 로직 코드만 지원하고 사용자 인터페이스 API에서 멀리 떨어져 있어야 합니다 (이전 지도의 외곽 구석에 '여기에 괴물이 있을 때'처럼 말).
• 일반적인 기반이 아닌 iOS Foundation Framework가 필요합니다.
• Apple의 메모리 관리 권장사항을 구현한 후 Xcode의 Instruments를 사용하여 허용되는 성능과 메모리 사용량을 확인하세요.
• 완전성을 위해 필요한 항목이 아닌 애플리케이션 개발자에게 필요한 부분에만 집중하세요. 실제 애플리케이션의 요구사항에 따라 프로젝트 요구사항이 달라집니다.

유용하며 여러분도 그럴 것입니다.

Google은 일부 내부 프로젝트에서 자바 비즈니스 로직을 iOS 앱과 공유하는 문제를 해결하는 데 J2ObjC를 오픈소스로 제공했습니다. 현재 여러 팀에서 번역사를 사용하고 있으며 Google은 새로운 기능을 추가하고 많은 버그를 수정하기 위해 최선을 다하고 있습니다. Google은 다른 모바일 앱팀을 시도해 보시고 효과적인 부분과 개선이 필요한 부분을 알려주세요.

또한 이 프로젝트를 진행하는 일에 보람을 느끼게 됩니다. 자바 변환기에게 가장 어려운 두 가지 작업은 1) 자바 소스의 올바른 파싱, 유형 확인 및 확인, 2) 호환되는 자바 런타임 환경을 제공하는 것입니다. 첫 번째 작업은 javac 컴파일러에서 잘 처리되며 런타임 환경 (단위 테스트 포함)은 Android libcore 라이브러리를 기반으로 합니다. 추상 구문 트리를 변형하고 일반적으로 디버그하기 쉬운 소스 출력을 생성하는 등 재미있는 일이 남아 있습니다. 자바 도구나 컴파일러에 관심이 있다면 참여해주세요! 아직도 할 일이 많습니다. 많은 도움 부탁드립니다.