Nadie ha podido llegar tarde a su funeral.
Valentin Domil
La semana pasada, un equipo de Google finalmente publicó el código fuente para el marco J2CL , del que se ha hablado desde 2015. La idea de traducir Java a JavaScript está lejos de ser nueva, y todos han llenado los conos con Google Web Toolkit, pero la comunidad estaba esperando este producto como ningún otro: hablaron sobre él e hicieron discursos, pero nadie lo vio.
Han pasado más de 3 años desde el primer anuncio y parece que el producto ha perdido el mercado sin siquiera haber nacido. Hoy tenemos Scala.js , Kotlin.js y JSweet , sin mencionar que el desarrollo web ha sido secuestrado por TypeScript y no queda espacio para Java. Durante este tiempo, muchos, incluso los javists más dedicados, han perdido la fe en "Java for Front-end" y han frenado este o aquel framework de JavaScript.
Dado que el lanzamiento sucedió, veamos qué sucedió y a quién podría serle útil.
Idea
Básicamente, emular JVM en un navegador es una tarea difícil. Los desarrolladores de Google Web Toolkit lo han estado resolviendo durante mucho tiempo y han logrado ciertos éxitos: crearon un traductor, desarrollaron mecanismos de emulación para la biblioteca estándar de Java y proporcionaron ajustes para el desarrollo de aplicaciones.
Este enfoque tiene muchas ventajas: la escritura estática, la capacidad de reutilizar el código del servidor en un navegador y las herramientas listas para usar en forma de IDE de Java. Muchos de los enfoques establecidos originalmente en GWT ahora se ven en TypeScript, Web Pack y otras herramientas de desarrollo front-end.
El antiguo Google Web Toolkit no era del agrado de su volumen y su abstracción para construir una interfaz de usuario. La idea de J2CL es más simple: le permite traducir Java a JavaScript al menor costo posible, de modo que pueda llamar fácilmente a Java desde JavaScript y viceversa.
Y si en 2015 realmente hubiera habido un traductor de Java de alta calidad en JS sin basura innecesaria, no se sabe cómo se desarrollaría aún más el desarrollo web.
Antecedentes J2CL
A principios de 2015, el equipo de Google GWT tomó una decisión difícil pero necesaria: desarrollar un nuevo producto que le permita utilizar Java en el desarrollo front-end.
Esto se debió principalmente a las tendencias cambiantes en el desarrollo web y sus nuevos clientes internos, que vieron Java para la web no como un ecosistema aislado, sino como una parte integral de una gran pila. Esto requirió una visión completamente nueva y la creación de herramientas desde cero, que deberían integrarse estrechamente con el resto del ecosistema.
Con GWT, era casi imposible lograr estos objetivos. Aunque había herramientas para la interacción bidireccional con JavaScipt en el GWT, el marco no podía deshacerse de una gran cantidad de equipaje en forma de una interfaz de usuario, biblioteca RPC y otras API de aplicaciones.
¿Qué es esta bestia?
Según los desarrolladores , J2CL proporciona una integración perfecta del código Java en aplicaciones JavaScript. Es un traductor de Java a JavaScript simple y liviano con un enfoque en la optimización del código utilizando el Compilador de cierre .
- Puede mezclar fácilmente Java y JavaScript en un proyecto, obteniendo lo mejor de cada uno de los idiomas.
- Permite la reutilización de código entre una solución de servidor, una aplicación web y la plataforma Android. Hay una gran cantidad de bibliotecas Java disponibles, como: Guava, Dagger y AutoValue.
- Moderno y confortable. El ensamblaje de proyectos se basa en Bazel , compatible con Live-reload.
- Verificado Se afirma que J2CL se utiliza en producción en proyectos GSuite: GMail, Docs, Slides y Calendar.
Esencialmente, J2CL traduce el código fuente de Java en código JavaScript sin usar el código de bytes de la clase Java. Esto significa que, como en el caso de Google Web Toolkit, se necesita el código fuente de todas las bibliotecas utilizadas para compilar el proyecto. Además, esto plantea preguntas sobre el soporte para las características del lenguaje Java en las nuevas versiones. Por el momento, los desarrolladores prometen soporte para todas las características de sintaxis de Java 11.
J2CL no admitirá GWT Widgets, GWT RPC y otras bibliotecas GWT, solo Java básico y el motor de integración de JavaScript, JSInterop .
Es decir Esta es una versión muy limitada de GWT con un transportador completamente nuevo. Y, dado que el nuevo producto ya no es compatible con GWT, no se llama GWT, sino J2CL. Como resultado, el lanzamiento planificado de GWT 3 será un marco sobre J2CL, donde todas las bibliotecas de aplicaciones se separarán del nivel del sistema del traductor.
Las restricciones de compatibilidad de Java existentes se describen en GitHub . Básicamente, permanecieron igual que en GWT: no hay soporte de reflexión, ni API de red Java. Pero algo es diferente: la semántica de las matrices y las listas no se emula, por ejemplo, el índice no comprueba las ocurrencias en los límites de las matrices. Los desarrolladores no se centran en emular el comportamiento de JVM, sino en la sintaxis del lenguaje para garantizar una sobrecarga mínima y no generar toneladas de JavaScript para garantizar la compatibilidad total.
Aunque J2CL está listo para la producción, su versión OSS aún está lejos de serlo. Por ejemplo, hay problemas al iniciar proyectos en Windows y los desarrolladores no prometen una API estable.
La elección de Bazel como sistema de compilación para el producto interno de Google es fácil de explicar, pero no hay ventajas para la comunidad, y no hay otra forma de usar J2CL que aprender este sistema de compilación. Todo lo que queda es esperar a que la comunidad escriba complementos para Maven / Gradle.
Prueba
Primero, para probar J2CL ahora, necesita Mac OS o Linux.
En segundo lugar, debe instalar Bazel , un sistema de compilación algo exótico de Google.
Ahora puede al menos recopilar algo, por ejemplo, HelloWorld del repositorio oficial.
> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld
Si miramos la conclusión, nos sorprenderemos gratamente:
> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js document.write('Hello from Java! and JS!');
Por supuesto, esto no prueba nada, pero está muy satisfecho con su minimalismo después de los módulos GWT. Todavía no hay grandes ejemplos de aplicaciones, esperaremos su aparición.
¿Por qué es necesario si hay xxx.js
La respuesta a la pregunta de por qué esto necesita ser encontrado todavía es difícil. A primera vista, J2CL tiene una idea muy fuerte: reutilizar Java para la interfaz al igual que las personas usan TypeScript. Por otro lado, el proyecto parece llegar tarde.
Los proyectos de transportadores más nuevos en JS, como Kotlin.js y Scala.js, se implementan como complementos del compilador y no necesitan volver a analizar el código fuente. Y a este respecto, J2CL es un paso atrás, porque necesita el código fuente que analizará.
Un punto separado es el lenguaje Java en sí. ¿Por qué escribir en Java detallado si puede escribir tanto el servidor como la parte del cliente en Kotlin conciso?
Aunque, en comparación con otro proyecto similar, JSweet , confío más en J2CL. Las herramientas de JSweet son mucho más amigables y están más listas para usar, pero JSweet tiene una comunidad pequeña y casi todas están escritas por una sola persona.
¿Dices código fuente abierto?
Ciertamente contento de que el proyecto tenga una licencia abierta para Apache 2.0.
Desafortunadamente, el código abierto no significa un proceso de desarrollo abierto . La mayor decepción de la comunidad vino de la situación actual, el proyecto J2CL se anunció hace 3 años, pero nadie muestra su código fuente, no puede influir en su API final y no acelerar el proceso de desarrollo, porque no hay ningún lugar para enviar parches.
Esperemos que la situación mejore y el producto se vuelva viable.
Actualización: primera aplicación J2CL portada desde GWT2 - https://github.com/DominoKit/dominodo