A motivação por trás do J2ObjC

A J2ObjC começou com frustração. A frustração que várias equipes de desenvolvimento tiveram ao tentar iterar rapidamente seus produtos da Web e para dispositivos móveis sem que eles se alterassem da funcionalidade. Muitos dos produtos clientes do Google foram criados usando o GWT para apps da Web (agora J2CL) e a API do Android para dispositivos móveis Android. Com isso, restavam os aplicativos para iPod/iPad, que precisavam ser apps da Web em JavaScript ou escritos à mão em Objective-C. Embora os apps GWT e Android pudessem compartilhar código de lógica de negócios (que não seja da interface), não havia solução para compartilhar esse código com apps iOS.

Investigamos várias abordagens para resolver esse problema. O XMLVM parecia muito promissor, mas, na época, a página tradutor para iOS declarou que o projeto foi suspenso (agora ele está ativo novamente e é uma boa alternativa). Outras ferramentas de tradução fizeram uma conversão única de código, exigindo edições adicionais antes que a saída fosse criada e executada.

Um novo projeto nasce

Desde o início, muitos engenheiros pensaram que um tradutor como o J2ObjC não era possível. É impossível criar uma ferramenta capaz de traduzir com precisão todo o código do aplicativo Java para o iOS e preservar perfeitamente a semântica dele. Isso porque o iOS tem padrões rigorosos de design de interface do usuário, e os usuários sabem quando um app não segue esses padrões. Na nossa opinião, a única maneira de ter uma interface do usuário rápida e de nível internacional para iOS é criá-la em Objective-C usando os frameworks do SDK do iOS da Apple.

No entanto, como a maioria dos engenheiros aprendeu com os limites do cálculo diferencial, pode ser muito útil chegar perto do impossível. Portanto, definimos um conjunto de limites que melhoraria as chances de sucesso do J2ObjC:

• Suporte apenas ao desenvolvimento do lado do cliente. Em teoria, as ferramentas de linha de comando e o código do servidor podem ser convertidos, mas esse caso de uso provavelmente tem problemas não resolvidos pelo J2ObjC.
• oferecem suporte apenas ao código de lógica de negócios e ficam muito longe das APIs da interface do usuário (como os mapas antigos costumavam ter nos cantos superiores, "aqui tem monstros").
• Exija o framework do iOS Foundation, não uma base mais geral.
• Use os Instrumentos do Xcode (link em inglês) para verificar o desempenho e o uso de memória aceitáveis, depois de implementar as práticas recomendadas da Apple para gerenciamento de memória.
• Concentre-se apenas no que é necessário pelos desenvolvedores de aplicativos, e não no que é necessário para a integridade. As necessidades reais dos aplicativos orientam os requisitos do projeto.

Talvez seja útil, talvez você também queira

Lançamos o J2ObjC porque alguns projetos internos resolveram o problema de compartilhar a lógica de negócios Java com os apps iOS. Várias equipes dependem do tradutor agora, e estamos trabalhando para adicionar novas funcionalidades e corrigir vários bugs. Aceitamos que outras equipes de apps para dispositivos móveis experimentem o recurso e nos conte o que funciona e o que precisa melhorar.

Também achamos gratificante trabalhar no projeto. As duas tarefas mais difíceis para qualquer tradutor Java são 1) analisar corretamente, verificar de tipo e resolver código-fonte Java e 2) fornecer um ambiente de execução Java compatível. A primeira tarefa é gerenciada bem pelo compilador javac, e o ambiente de execução (incluindo os testes de unidade) é baseado na biblioteca Android libcore. Isso deixa a parte divertida para nós: modificar árvores de sintaxe abstrata e gerar saídas de origem geralmente fáceis de depurar. Se você tiver interesse em ferramentas ou compiladores Java, junte-se a nós! Ainda há muito a fazer, e adoraríamos receber ajuda.