La motivación detrás de J2ObjC

J2ObjC comenzó por frustración y frustración que sentían varios equipos de desarrollo al intentar iterar rápidamente sus productos web y móviles sin que se desviaran en la funcionalidad. Muchos de los productos cliente de Google se crearon con GWT para apps web (ahora J2CL) y la API de Android para dispositivos móviles Android. Eso dejó apps para iPod/iPad, que debían ser apps web de JavaScript o escribirse a mano en Objective-C. Aunque GWT y las apps para Android podían compartir código de lógica empresarial (sin IU), no había ninguna solución para compartir ese código con apps para iOS.

Se investigaron varios enfoques para resolver este problema. XMLVM parecía muy prometedor, pero en ese momento, la página de traductor de iOS indicó que el proyecto se suspendió (ahora está activo de nuevo y es una buena alternativa a este proyecto). Otras herramientas de traducción realizaban conversiones de código por única vez y requerían edición adicional antes de que los resultados se compilaran y se ejecutaran correctamente.

Nace un nuevo proyecto

Desde el principio, muchos ingenieros pensaron que un traductor como J2ObjC no era posible. Es realmente imposible crear una herramienta que pueda traducir con precisión todo el código de la aplicación Java a iOS y, al mismo tiempo, preservar a la perfección su semántica. Esto se debe a que iOS tiene estándares rigurosos de diseño de interfaces de usuario, y sus usuarios son muy conscientes de cuándo una app no los cumple. En nuestra opinión, la única forma de obtener una IU rápida y de primer nivel para iOS es escribirla en Objective-C con los frameworks del SDK de iOS de Apple.

Sin embargo, como la mayoría de los ingenieros aprendieron de los límites del cálculo diferencial, puede ser muy útil acercarse a lo imposible. Por lo tanto, establecimos un conjunto de límites que mejorarían las posibilidades de que J2ObjC tenga éxito:

• Solo es compatible con el desarrollo del cliente. En teoría, las herramientas de línea de comandos y el código del servidor podrían traducirse, pero es probable que ese caso de uso tenga problemas que J2ObjC no abordó.
• Solo es compatible con el código de lógica empresarial y se mantiene lejos de las APIs de interfaz de usuario (como solían tener los mapas antiguos en sus esquinas periféricas, "aquí hay monstruos").
• Requiere el framework de base de iOS, no una base más general.
• Usa instrumentos de Xcode para verificar el rendimiento y el uso de memoria aceptables después de implementar las prácticas recomendadas de Apple para la administración de memoria.
• Enfócate únicamente en lo que necesitan los desarrolladores de aplicaciones y no en lo que necesitan para completar la app. Las necesidades reales de las aplicaciones impulsan los requisitos del proyecto.

Creemos que es útil y tal vez tú también lo sea

Utilizamos J2ObjC de código abierto, ya que algunos proyectos internos descubrieron que esta solución resuelve el problema de compartir la lógica empresarial de Java con sus apps para iOS. Varios equipos ahora dependen del traductor, por lo que estamos ocupados agregando funcionalidad nueva y corrigiendo muchos errores. Brindamos la bienvenida a otros equipos de apps para dispositivos móviles que lo prueben y nos cuenten qué funciona y qué debemos mejorar.

También consideramos gratificante trabajar en el proyecto. Las dos tareas más difíciles para cualquier traductor de Java son 1) analizar correctamente, verificar el tipo y resolver la fuente de Java, y 2) proporcionar un entorno de ejecución de Java compatible. El compilador javac controla bien la primera tarea, y el entorno de ejecución (incluidas sus pruebas de unidades) se basa en la biblioteca libcore de Android. Eso nos deja una parte divertida: la mutación de árboles de sintaxis abstractos y la generación de resultados de origen que suelen ser fáciles de depurar. Si te interesan las herramientas o los compiladores de Java, únete a nosotros. Todavía queda mucho por hacer y nos encantaría ayudarte.