Motywacja działań J2ObjC

Firma J2ObjC zaczynała się z frustracji, co było frustracją z powodu tego, że kilka zespołów programistów musiało szybko iterować swoje usługi internetowe i mobilne, tak by funkcjonowały jak zwykle. Wiele usług klienckich Google powstało przy użyciu GWT do obsługi aplikacji internetowych (obecnie J2CL) oraz interfejsu Android API na urządzenia mobilne z Androidem. Z tego powodu aplikacje na iPoda lub iPada musiały być napisane w języku JavaScript albo odręcznie napisane w języku Objective-C. Mimo że aplikacje GWT i aplikacje na Androida mogły współdzielić kod logiki biznesowej (nie w interfejsie), nie było rozwiązania, które pozwalałoby udostępnić ten kod aplikacjom na iOS.

Przeanalizowano kilka metod rozwiązania tego problemu. Projekt XMLVM wyglądał obiecująco, ale w momencie na stronie tłumacza na iOS można było stwierdzić, że projekt został zawieszony (jest znowu aktywny i stanowi dobrą alternatywę dla niego). Inne narzędzia do translacji dokonały jednorazowej konwersji kodu, która wymagała dodatkowej edycji, zanim dane wyjściowe będą mogły zostać skompilowane i uruchomione.

Narodziny nowego projektu

Wielu inżynierów uważał, że tłumacz taki jak J2ObjC nie jest w stanie. Stworzenie narzędzia, które dokładnie przetłumaczy cały kod aplikacji w Javie na iOS, zachowując pełną semantykę, jest absolutnie niemożliwe. Wynika to z tego, że interfejs na iOS ma rygorystyczne standardy dotyczące projektowania, a użytkownicy urządzeń wiedzą, że aplikacje ich nie spełniają. Naszym zdaniem jedynym sposobem na uzyskanie światowej klasy szybkiego interfejsu użytkownika na iOS jest napisanie go w języku Objective-C przy użyciu platform SDK iOS firmy Apple.

Jednak większość inżynierów uczyła się z granic w rachunku różniczkowym, jednak bardzo przydatne może być zbliżenie się do tego, co jest niemożliwe. Dlatego wprowadziliśmy zestaw ograniczeń, które zwiększyłyby szanse na sukces projektu J2ObjC:

• Obsługuje tylko programowanie po stronie klienta. Narzędzia wiersza poleceń i kod serwera w teorii mogą być przetłumaczone, ale w tym przypadku mogą występować problemy, które nie są rozwiązywane przez J2ObjC.
• Obsługuj tylko kod logiki biznesowej i trzymaj się z dala od interfejsów API interfejsu (jak w starych mapach w odległych zakątkach świata „tutaj są potwory”).
• Wymagaj szablonu podstaw dla iOS, a nie bardziej ogólnej podstawy.
• Użyj narzędzia Xcode's Instruments do zweryfikowania dopuszczalnego użytkowania pamięci po wdrożeniu sprawdzonych metod firmy Apple dotyczących zarządzania pamięcią.
• Skup się tylko na tym, co jest niezbędne dla programistów aplikacji, a nie na tym, co jest niezbędne. Rzeczywiste potrzeby aplikacji wpływają na wymagania projektu.

Uważamy, że warto i Ty też

Opracowaliśmy oprogramowanie open source J2ObjC, ponieważ w niektórych projektach wewnętrznych udało się nam rozwiązać problem z udostępnianiem logiki biznesowej w języku Java w aplikacjach na iOS. Kilka zespołów zawdzięcza obecnie pracę tłumaczowi – stale dodajemy nowe funkcje i naprawiamy mnóstwo błędów. Zachęcamy inne zespoły ds. aplikacji mobilnych do wypróbowania tej usługi i daj nam znać, co działa, a co wymaga ulepszenia.

Praca nad projektem również daje nam satysfakcję. Dwa najtrudniejsze zadania dla każdego tłumacza w języku Java to: 1) prawidłowa analiza składni, sprawdzenie typu i rozwiązanie kodu źródłowego w języku Java oraz 2) stworzenie zgodnego środowiska wykonawczego Java. Pierwsze zadanie jest dobrze wykonywane przez kompilator Javac, a środowisko wykonawcze (w tym jego testy jednostkowe) opiera się na bibliotece Android libcore. To daje nam satysfakcję: mutowanie abstrakcyjnych drzew składni i generowanie zwykle łatwego do debugowania danych wyjściowych źródła. Jeśli interesują Cię narzędzia i kompilatory Java, dołącz do nas! Jest jeszcze wiele do zrobienia. Chętnie Ci pomożemy.