Personne n'a encore pu être en retard pour leurs funérailles.
Valentin Domil
La semaine dernière, une équipe de Google a finalement publié le code source du framework J2CL , dont on parle depuis 2015. L'idée de traduire Java en JavaScript est loin d'être nouvelle, et tout le monde a longtemps rempli les cônes avec Google Web Toolkit, mais la communauté attendait ce produit pas comme les autres - ils en ont parlé et prononcé des discours, mais personne ne l'a vu.
Plus de 3 ans se sont écoulés depuis la première annonce et il semble que le produit ait perdu le marché sans même être né. Aujourd'hui, nous avons Scala.js , Kotlin.js et JSweet , sans oublier que le développement Web a été détourné par TypeScript et qu'il n'y a plus d'espace pour Java. Pendant ce temps, beaucoup, même les javistes les plus dévoués, ont perdu confiance en «Java for Front-end» et ont freiné tel ou tel framework JavaScript.
Depuis la sortie, voyons ce qui s'est passé et à qui cela pourrait être utile.
Idée
Fondamentalement, l'émulation de machines virtuelles Java dans un navigateur est une tâche difficile. Les développeurs de Google Web Toolkit le résolvent depuis longtemps et ont obtenu certains succès: ils ont construit un traducteur, développé des mécanismes d'émulation pour la bibliothèque Java standard et fourni des réglages pour le développement d'applications.
Cette approche présente de nombreux avantages: la saisie statique, la possibilité de réutiliser le code du serveur dans un navigateur et des outils prêts à l'emploi sous la forme d'un IDE Java. De nombreuses approches initialement définies dans GWT sont désormais visibles dans TypeScript, Web Pack et d'autres outils de développement frontaux.
L'ancien Google Web Toolkit n'était pas apprécié pour son encombrement et son abstraction pour la construction d'une interface utilisateur. L'idée de J2CL est plus simple - vous permettant de traduire Java en JavaScript au coût le plus bas possible, afin que vous puissiez facilement appeler Java à partir de JavaScript et vice versa.
Et si en 2015 il y aurait vraiment eu un traducteur Java de haute qualité dans JS sans ordures inutiles, on ne sait pas comment le développement Web se développerait davantage.
Contexte J2CL
Début 2015, l'équipe Google GWT a pris une décision difficile mais nécessaire: développer un nouveau produit qui vous permet d'utiliser Java dans le développement frontal.
Cela était principalement dû aux tendances changeantes du développement Web et de leurs nouveaux clients internes, qui considéraient Java pour le Web non pas comme un écosystème isolé, mais comme partie intégrante d'une grande pile. Cela a nécessité une vision complètement nouvelle et la création d'outils à partir de zéro, qui devraient être étroitement intégrés avec le reste de l'écosystème.
Avec GWT, il était presque impossible d'atteindre ces objectifs. Bien qu'il y ait des outils d'interaction bidirectionnelle avec JavaScipt dans le GWT, le cadre n'a pas pu se débarrasser de beaucoup de bagages sous la forme d'une interface utilisateur, d'une bibliothèque RPC et d'autres API d'application.
Quelle est cette bête
Selon les développeurs , J2CL fournit une intégration transparente du code Java dans les applications JavaScript. Il s'agit d'un traducteur Java vers JavaScript simple et léger axé sur l'optimisation du code à l'aide du compilateur de fermeture .
- Vous pouvez facilement mélanger Java et JavaScript dans un seul projet, en tirant le meilleur parti de chacune des langues.
- Permet la réutilisation du code entre une solution serveur, une application Web et la plate-forme Android. Un grand nombre de bibliothèques Java sont disponibles, telles que: Guava, Dagger et AutoValue.
- Moderne et confortable. L'assemblage des projets est basé sur Bazel , soutenu par Live-reload.
- Vérifié. On prétend que J2CL est utilisé dans la production dans les projets GSuite: GMail, Docs, Slides et Calendar.
Essentiellement, J2CL traduit le code source Java en code JavaScript sans utiliser le bytecode de la classe Java. Cela signifie que, comme dans le cas de Google Web Toolkit, le code source de toutes les bibliothèques utilisées est nécessaire pour compiler le projet. De plus, cela soulève des questions sur la prise en charge des fonctionnalités du langage Java dans les nouvelles versions. À l'heure actuelle, les développeurs promettent la prise en charge de toutes les fonctionnalités de syntaxe de Java 11.
J2CL ne prend pas en charge les widgets GWT, GWT RPC et d'autres bibliothèques GWT - uniquement Java de base et le moteur d'intégration JavaScript, JSInterop .
C'est-à-dire Il s'agit d'une version très limitée de GWT avec un tout nouveau transporteur. Et, comme le nouveau produit n'est plus compatible avec GWT, il s'appelle non pas GWT, mais J2CL. En conséquence, la version prévue de GWT 3 sera un framework au-dessus de J2CL, où toutes les bibliothèques d'applications seront séparées du niveau système du traducteur lui-même.
Les restrictions de compatibilité Java existantes sont décrites sur GitHub . Fondamentalement, ils sont restés les mêmes que dans GWT - il n'y a pas de support de réflexion, pas d'API réseau Java. Mais quelque chose est différent - la sémantique des tableaux et des listes n'est pas émulée, par exemple, l'index ne vérifie pas les occurrences dans les limites des tableaux. Les développeurs ne se concentrent pas sur l'émulation du comportement JVM, mais sur la syntaxe du langage pour garantir une surcharge minimale et ne pas générer des tonnes de JavaScript pour assurer une compatibilité totale.
Bien que J2CL soit prêt pour la production, sa version OSS en est encore loin. Par exemple, il y a des problèmes pour démarrer des projets sous Windows et les développeurs ne promettent pas une API stable.
Le choix de Bazel comme système de build pour le produit interne de Google est facile à expliquer, mais il n'y a aucun avantage pour la communauté, et il n'y a pas d'autre moyen d'utiliser J2CL que d'apprendre ce système de build. Il ne reste plus qu'à attendre que la communauté écrive des plugins pour Maven / Gradle.
Essayez
Tout d'abord, pour essayer J2CL maintenant, vous avez besoin de Mac OS ou Linux.
Deuxièmement, vous devez installer Bazel - un système de construction quelque peu exotique de Google.
Maintenant, vous pouvez au moins collecter quelque chose, par exemple, HelloWorld à partir du référentiel officiel.
> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld
Si nous regardons la conclusion, nous serons agréablement surpris:
> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js document.write('Hello from Java! and JS!');
Bien sûr, cela ne prouve rien, mais il est très satisfait de son minimalisme après les modules GWT. Il n'y a pas encore de grands exemples d'applications, nous attendrons leur apparition.
Pourquoi est-il nécessaire s'il y a xxx.js
La réponse à la question de savoir pourquoi cela doit être trouvé est toujours difficile. À première vue, J2CL a une idée très forte - réutiliser Java pour le frontend tout comme les gens utilisent TypeScript. En revanche, le projet semble être en retard.
De nouveaux projets de transpilateur dans JS, tels que Kotlin.js et Scala.js, sont implémentés en tant que plugins de compilation et n'ont pas besoin de ré-analyser le code source. Et à cet égard, J2CL est un pas en arrière, car il a besoin du code source qu'il analysera.
Un point distinct est le langage Java lui-même. Pourquoi écrire en Java verbeux, si vous pouvez écrire à la fois le serveur et la partie client en Kotlin concis?
Bien que, comparé à un autre projet similaire - JSweet , je fais davantage confiance à J2CL. L'outillage JSweet est beaucoup plus convivial et plus prêt à l'emploi, mais JSweet a une petite communauté et il est presque entièrement écrit par une seule personne.
Vous dites le code open source?
Certainement heureux que le projet dispose d'une licence ouverte pour Apache 2.0.
Malheureusement, l' open source ne signifie pas un processus de développement ouvert . La plus grande déception de la communauté est venue de la situation actuelle, le projet J2CL a été annoncé il y a 3 ans, mais personne ne montre son code source, vous ne pouvez pas influencer son API finale et ne pas accélérer le processus de développement, car il n'y a nulle part où envoyer des correctifs.
Espérons que la situation s'améliore et que le produit devienne viable.
Mise à jour: première application J2CL portée depuis GWT2 - https://github.com/DominoKit/dominodo