Ninguém ainda se atrasou para o funeral.
Valentin Domil
Na semana passada, uma equipe do Google finalmente publicou o código-fonte para o framework J2CL , sobre o qual se fala desde 2015. A idéia de traduzir Java para JavaScript está longe de ser nova, e todo mundo encheu os cones com o Google Web Toolkit, mas a comunidade estava esperando por este produto como nenhum outro - eles conversaram sobre isso e fizeram discursos, mas ninguém viu.
Mais de 3 anos se passaram desde o primeiro anúncio e parece que o produto perdeu o mercado sem sequer nascer. Hoje, temos Scala.js , Kotlin.js e JSweet , sem mencionar que o desenvolvimento da Web foi invadido pelo TypeScript e não resta espaço para Java. Durante esse período, muitos, mesmo os javistas mais dedicados, perderam a fé no “Java for Front-end” e restringiram essa ou aquela estrutura JavaScript.
Desde que o lançamento aconteceu, vamos ver o que aconteceu e para quem pode ser útil.
Idéia
Fundamentalmente, emular JVMs em um navegador é uma tarefa difícil. Os desenvolvedores do Google Web Toolkit vêm resolvendo esse problema há muito tempo e alcançaram certos sucessos: eles criaram um tradutor, desenvolveram mecanismos de emulação para a biblioteca Java padrão e forneceram ajustes para o desenvolvimento de aplicativos.
Há muitas vantagens nessa abordagem: digitação estática, capacidade de reutilizar o código do servidor em um navegador e ferramentas prontas na forma de um IDE Java. Muitas das abordagens originalmente estabelecidas no GWT agora são vistas no TypeScript, Web Pack e outras ferramentas de desenvolvimento front-end.
O antigo Google Web Toolkit não era apreciado por seu volume e abstração por criar uma interface do usuário. A idéia do J2CL é mais simples, permitindo que você traduza Java para JavaScript pelo menor custo possível, para que você possa facilmente chamar Java de JavaScript e vice-versa.
E se em 2015 realmente houvesse um tradutor Java de alta qualidade em JS sem lixo desnecessário, não se sabe como o desenvolvimento da Web se desenvolveria ainda mais.
J2CL em segundo plano
No início de 2015, a equipe do Google GWT tomou uma decisão difícil, mas necessária - desenvolver um novo produto que permita usar Java no desenvolvimento front-end.
Isso ocorreu principalmente devido às novas tendências no desenvolvimento da Web e a seus novos clientes internos, que viam o Java para a Web não como um ecossistema isolado, mas como parte integrante de uma grande pilha. Isso exigiu uma visão completamente nova e a criação de ferramentas do zero, que devem ser estreitamente integradas ao restante do ecossistema.
Com o GWT, era quase impossível alcançar esses objetivos. Embora houvesse ferramentas para interação bidirecional com o JavaScipt no GWT, a estrutura não conseguia se livrar de muita bagagem na forma de uma interface do usuário, biblioteca RPC e outras APIs de aplicativos.
O que é essa fera
Segundo os desenvolvedores , o J2CL fornece integração perfeita do código Java em aplicativos JavaScript. É um conversor de Java para JavaScript simples e leve, com foco na otimização de código usando o Closure Compiler .
- Você pode facilmente misturar Java e JavaScript em um projeto, obtendo o melhor de cada um dos idiomas.
- Permite a reutilização de código entre uma solução de servidor, um aplicativo Web e a plataforma Android. Um grande número de bibliotecas Java está disponível, como: Guava, Dagger e AutoValue.
- Moderno e confortável. A montagem dos projetos é baseada no Bazel , suportado pelo Live-reload.
- Verificado. Alega-se que o J2CL é usado na produção em projetos do GSuite: GMail, Docs, Slides e Calendar.
Essencialmente, o J2CL converte o código-fonte Java em código JavaScript sem usar o bytecode da classe Java. Isso significa que, como no caso do Google Web Toolkit, o código-fonte de todas as bibliotecas usadas é necessário para compilar o projeto. Além disso, isso levanta questões sobre o suporte aos recursos da linguagem Java em novos lançamentos. No momento, os desenvolvedores prometem suporte para todos os recursos de sintaxe do Java 11.
O J2CL não suportará Widgets GWT, GWT RPC e outras bibliotecas GWT - apenas Java básico e o mecanismo de integração JavaScript, JSInterop .
I.e. Esta é uma versão muito limitada do GWT com um transportador completamente novo. E, como o novo produto não é mais compatível com o GWT, ele é chamado não de GWT, mas de J2CL. Como resultado, a liberação planejada do GWT 3 será uma estrutura sobre o J2CL, onde todas as bibliotecas de aplicativos serão separadas do nível do sistema do próprio tradutor.
As restrições de compatibilidade Java existentes são descritas no GitHub . Basicamente, eles permaneceram os mesmos do GWT - não há suporte para reflexão, nem API de rede Java. Mas algo é diferente - a semântica de matrizes e listas não é emulada, por exemplo, o índice não verifica se há ocorrências nos limites das matrizes. Os desenvolvedores não se concentram em emular o comportamento da JVM, mas na sintaxe da linguagem para garantir uma sobrecarga mínima e não gerar toneladas de JavaScript para garantir compatibilidade total.
Embora o J2CL esteja pronto para produção, sua versão do OSS ainda está longe disso. Por exemplo, há problemas ao iniciar projetos no Windows e os desenvolvedores não prometem uma API estável.
É fácil explicar a escolha de Bazel como o sistema de criação do produto interno do Google, mas não há vantagens para a comunidade e não há outra maneira de usar o J2CL a não ser aprender esse sistema de criação. Tudo o que resta é esperar a comunidade escrever plugins para o Maven / Gradle.
Experimente
Primeiro, para experimentar o J2CL agora, você precisa do Mac OS ou Linux.
Em segundo lugar, você precisa instalar o Bazel - um sistema de criação um tanto exótico do Google.
Agora você pode pelo menos coletar algo, por exemplo, HelloWorld no repositório oficial.
> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld
Se olharmos para a conclusão, ficaremos agradavelmente surpreendidos:
> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js document.write('Hello from Java! and JS!');
Obviamente, isso não prova nada, mas está muito satisfeito com seu minimalismo após os módulos GWT. Ainda não existem ótimos exemplos de aplicativos; aguardaremos o aparecimento deles.
Por que é necessário se houver xxx.js
A resposta à pergunta por que isso precisa ser encontrado ainda é difícil. À primeira vista, o J2CL tem uma idéia muito forte - reutilizar o Java para o front-end, assim como as pessoas usam o TypeScript. Por outro lado, o projeto parece estar atrasado.
Projetos de transportadores mais recentes em JS, como Kotlin.js e Scala.js, são implementados como plug-ins de compilador e não precisam analisar novamente o código-fonte. E nesse sentido, o J2CL está um passo atrás, porque precisa do código-fonte que analisará.
Um ponto separado é a própria linguagem Java. Por que escrever em Java detalhado, se você pode escrever a parte do servidor e do cliente no Kotlin conciso?
Embora, quando comparado com outro projeto semelhante - o JSweet , confio mais no J2CL. As ferramentas do JSweet são muito mais amigáveis e mais prontas para uso, mas o JSweet tem uma pequena comunidade e é quase todo escrito por uma pessoa.
Você diz código fonte aberto?
Certamente satisfeito por o projeto ter uma licença aberta para o Apache 2.0.
Infelizmente, código aberto não significa um processo de desenvolvimento aberto . A maior decepção da comunidade veio da situação, o projeto J2CL foi anunciado há 3 anos, mas ninguém mostra seu código-fonte, você não pode influenciar sua API final e não acelerar o processo de desenvolvimento, porque não há para onde enviar patches.
Vamos torcer para que a situação melhore e o produto se torne viável.
Atualização: primeiro aplicativo J2CL portado do GWT2 - https://github.com/DominoKit/dominodo