La motivation derrière J2ObjC

J2ObjC a commencé par frustration : plusieurs équipes de développement avaient été frustrées d'essayer d'itérer rapidement leurs produits Web et mobiles sans qu'elles ne s'éloignent des fonctionnalités. De nombreux produits clients de Google ont été créés à l'aide de GWT pour les applications Web (désormais J2CL) et de l'API Android pour les appareils mobiles Android. Il restait les applications iPod/iPad, qui devaient être des applications web JavaScript ou écrites à la main en Objectif-C. Bien que les applications GWT et Android puissent partager du code de logique métier (hors UI), il n'existait pas de solution pour partager ce code avec les applications iOS.

Plusieurs approches pour résoudre ce problème ont été étudiées. XMLVM semblait très prometteur, mais à ce moment-là, la page du traducteur iOS indiquait que le projet était suspendu (il est désormais actif et constitue une bonne alternative à ce projet). D'autres outils de traduction convertissent le code une seule fois, nécessitant des modifications supplémentaires pour que la création et l'exécution du résultat aboutissent.

Naissance d'un nouveau projet

Dès le départ, de nombreux ingénieurs pensaient qu'un traducteur comme J2ObjC n'était pas possible. Il est en effet impossible de créer un outil capable de traduire avec précision tout le code d'application Java vers iOS tout en préservant parfaitement sa sémantique. Cela est dû au fait qu'iOS applique des normes de conception d'interface utilisateur rigoureuses et que ses utilisateurs savent parfaitement qu'une application ne les respecte pas. Selon nous, le seul moyen d'obtenir une interface utilisateur iOS rapide et de premier ordre consiste à l'écrire en Goal-C à l'aide des frameworks de SDK iOS d'Apple.

Toutefois, comme la plupart des ingénieurs l'ont appris à partir des limites du calcul différentiel, il peut être très utile de s'approcher de l'impossible. Nous avons donc défini un ensemble de limites qui amélioreraient les chances de réussite de J2ObjC:

• Compatible uniquement avec le développement côté client. En théorie, les outils de ligne de commande et le code du serveur peuvent être traduits, mais ce cas d'utilisation est susceptible de rencontrer des problèmes qui ne seront pas résolus par J2ObjC.
• N'acceptez que le code de logique métier et restez loin des API d'interface utilisateur (comme les anciennes cartes l'avaient dans leurs coins périphériques, "ici, il y a des monstres").
• Exigez le framework de base iOS, et non une base plus générale.
• Utilisez les instruments de Xcode pour vérifier que les performances et l'utilisation de la mémoire sont acceptables, après avoir appliqué les bonnes pratiques d'Apple en matière de gestion de mémoire.
• Concentrez-vous uniquement sur ce qui est nécessaire par les développeurs d'applications, plutôt que sur ce qui est nécessaire pour l'exhaustivité. Les besoins des applications réelles déterminent les exigences des projets.

Nous le trouvons utile, peut-être que vous le ferez peut-être aussi

Nous avons lancé la plate-forme J2ObjC en Open Source, car certains projets internes ont constaté qu'elle permettait de résoudre le problème lié au partage de la logique métier Java avec leurs applications iOS. Plusieurs équipes comptent maintenant sur le traducteur, et nous travaillons activement à ajouter de nouvelles fonctionnalités et à corriger de nombreux bugs. Nous invitons d'autres équipes d'applications mobiles à l'essayer. N'hésitez pas à nous indiquer ce qui fonctionne et ce qui doit être amélioré.

Nous trouvons également que travailler sur le projet est gratifiant. Les deux tâches les plus difficiles pour tout traducteur Java sont 1) l'analyse correcte, la vérification du type et la résolution de la source Java, et 2) la fourniture d'un environnement d'exécution Java conforme. La première tâche est bien gérée par le compilateur javac, et l'environnement d'exécution (y compris ses tests unitaires) est basé sur la bibliothèque libcore Android. Il nous reste donc une partie amusante: la mutation des arborescences syntaxiques abstraites et la génération d'une sortie source généralement facile à déboguer. Si les outils ou compilateurs Java vous intéressent, rejoignez-nous ! Il y a encore beaucoup à faire et nous serions ravis de vous aider.