J2CL –迟到总比不到好

上周，Google团队终于发布了J2CL框架的源代码，自2015年以来就对此进行了讨论。将Java转换为JavaScript的想法根本不是什么新鲜事，而且每个人在使用Google Web Toolkit之前都遇到了麻烦该产品在社区中倍受关注-经过讨论并成为会议演讲的主题，但没人能看到它 。

自首次发布以来已经有3年多了，而且该产品似乎甚至在其诞生之前就失去了市场。 今天，我们有了Scala.js，Kotlin.js和JSweet，此外，该开发已经由TypeScript占用，并且Java不再有地方了。 这么长时间以来，即使是最热爱Java的人也对“ Java for Front end”失去了信心，并学到了一些JavaScript框架。

但是，由于它终于发布了，所以让我们看一下结果以及将其用于什么目的。

理念

在全球范围内，在浏览器中模拟JVM是一项相当复杂的任务。 Google Web Toolkit开发人员长期以来一直在尝试解决此问题并取得了一定的成功：他们建立了一个编译器，开发了标准的Java库仿真机制，为应用程序开发提供了工具。

这种方法具有许多优点：静态类型检查，浏览器中服务器代码的可重用性，以Java IDE表示的现成工具。 现在，TypeScript，Web Pack和其他前端开发工具中代表了GWT的许多内置方法。

优秀的旧版Google Web Toolkit因其笨重且抽象的UI构建方式而遭到反对。 J2CL的想法更简单–它使我们能够以最小的开销将Java转换为JavaScript，以便您可以轻松地从JavaScript调用Java，反之亦然。

即使在2015年末有一个非常不错的从Java到JS的转译器，都可以在没有哈希的情况下运行，但几乎不可能假设Web开发会如何发展。

J2CL前传

2015年初，Google GWT团队做出了艰难而紧急的决定-开发支持Java进行前端开发的新产品。

主要是由于Web开发趋势的变化及其新的内部客户，他们将Java for Web视为不是孤立的生态系统，而是将其视为大型堆栈的重要组成部分。 它需要一种完全创新的观点，并创建应该从头紧密集成到其余生态系统中的工具。

使用GWT几乎不可能实现这样的目标。 尽管GWT具有与JavaScipt双向交互的方式，但该框架无法摆脱UI，RPC库和其他应用API的巨大负担。

那是什么野兽

正如开发人员所声称的那样 ，J2CL将Java代码无缝集成到JavaScript应用程序中。 它代表了一个简单轻巧的Java-to-JavaScript 编译器 ，该编译器专注于借助Closure Compiler进行代码优化。

• • 在一个项目中轻松混合Java和JavaScript，以充分利用每种语言的优势。

实际上，J2CL将源Java代码转换为没有Java类字节码JavaScript代码。 这意味着，与Google Web Toolkit一样，项目编译需要所有使用的库源。 此外，它提出了最新版本支持的Java语言功能的问题。 在此阶段，开发人员承诺将支持Java 11的所有语法功能。

J2CL不支持GWT窗口小部件，GWT RPC和其他GWT库，仅支持基本的Java和JavaScript集成工具JSInterop 。

也就是说，这是一个非常有限的GWT版本，带有全新的编译器。 并且由于新产品不再与GWT兼容，因此称为J2CL而不是GWT。 总体而言，即将发布的GWT 3版本将代表基于J2CL的框架，其中所有适用的库都将与翻译器系统级别分开。

现有的Java兼容性限制在GitHub上进行了描述。 它们基本上与GWT中的相同-没有反射支持，没有网络Java API。 但是也有一些不同之处–不会模拟数组和列表的语义，例如，不执行数组中索引的检查。 开发人员重点放在JVM行为仿真上，而不是语言的语法上，以最大程度地减少开销成本并避免生成大量JavaScript以确保完全兼容性。

尽管J2CL已准备好投入生产，但其OSS版本离它还很遥远。 例如， Windows上的项目启动存在一些问题，开发人员无法保证稳定的API。

选择Bazel作为内部Google产品的构建系统是很公平的，但是它对社区没有任何好处，除了学习该构建系统之外，没有其他方法可以使用J2CL。 同时，我们只能等待社区为Maven / Gradle制作插件。

开始工作

首先，J2CL需要Mac OS或Linux。

其次，您必须安装Bazel –而不是Google制造的异国情调的构建系统。

现在，您可以从官方存储库中构建一些东西，例如HelloWorld。

> bazel build src/main/java/com/google/j2cl/samples/helloworld:helloworld

当您查看输出时，您会惊喜地发现：

> cat bazel-bin/src/main/java/com/google/j2cl/samples/helloworld/helloworld.js
document.write('Hello from Java! and JS!');

当然，它什么都没有证明，但是很高兴在所有GWT模块之后都能看到如此的简约。 没有其他应用程序示例，因此我们将等它们显示出来。

如果我们有xxx.js是什么意思

目前，很难说出它的用途。 乍一看，J2CL包含一个大胆的想法–以与TypeScript相同的方式将Java重用于前端。 另一方面，该项目似乎错过了机会。

诸如Kotlin.js和Scala.js之类的新JS transpiler项目被实现为编译器的插件，并且不需要源代码解析。 从这个角度来看，J2CL落后了一步，因为它需要进行源分析。

还有一个问题是Java本身。 当您可以在简洁的Kotlin上同时编写服务器端和客户端时，为什么还要使用冗长的Java？

但是，与另一个类似的项目JSweet相比 ，我更信任J2CL。 JSweet工具更友好，更实用，但是JSweet社区很小，几乎完全由一个人编写。

所以你说它是开源的？

该项目获得了Apache 2.0免费许可绝对是一个好消息。

不幸的是， 开放源代码与开放开发过程不同 。 社区最大的失望是由于当前的情况而出现的，J2CL项目是3年前宣布的，但是没有人显示其源代码，您无法影响其最终API或加快开发过程，因为无处可发送修补程序。

让我们希望情况会发生最好的变化，并且产品会投入使用。

翻译自: https://www.javacodegeeks.com/2018/12/j2cl-better-late-never.html