尚未有人能够为他们的葬礼迟到。
瓦伦丁·多米尔（Valentin Domil）
上周，来自Google的团队终于发布了J2CL框架的源代码，自2015年以来一直在讨论该源代码 。 将Java转换为JavaScript的想法并不是什么新鲜事，每个人都早就用Google Web Toolkit填补了空白，但是社区一直在等待这种产品，他们谈论并发表了演讲，但没有人看到它。
自首次发布以来，已经过去了3年多的时间，而且该产品似乎还没有诞生就失去了市场。 今天，我们有了Scala.js ， Kotlin.js和JSweet ，更不用说Web开发已经被TypeScript劫持了，并且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年，确实会有JS中的高质量Java转换程序而没有不必要的垃圾，则不知道Web开发将如何进一步发展。
后台J2CL
2015年初，Google GWT团队做出了一个艰难但必要的决定-开发一种新产品，使您可以在前端开发中使用Java。
这主要是由于Web开发及其新的内部客户趋势的变化，他们将Java的Web视为一个孤立的生态系统，而不是孤立的生态系统，而是一个大型堆栈的组成部分。 这需要全新的视野并从头开始创建工具，这些工具应与生态系统的其余部分紧密集成。
使用GWT，几乎不可能实现这些目标。 尽管GWT中有一些与JavaScipt进行双向交互的工具，但该框架无法摆脱UI，RPC库和其他应用程序API的形式带来的麻烦。
这是什么野兽
根据开发人员的说法，J2CL在JavaScript应用程序中提供了Java代码的无缝集成。 它是一个简单，轻量级的Java到JavaScript转换器，专注于使用Closure Compiler进行代码优化。
- 您可以轻松地在一个项目中混合使用Java和JavaScript，从而从每种语言中获得最大的收益。
- 允许在服务器解决方案，Web应用程序和Android平台之间重复使用代码。 有许多Java库可供使用，例如：Guava，Dagger和AutoValue。
- 现代而舒适。 项目的组装基于Live Reload支持的Bazel 。
- 已验证。 据称，J2CL已用于GSuite项目的生产中：GMail，Docs，Slides和Calendar。
本质上，J2CL无需使用Java类字节码即可将Java源代码转换为JavaScript代码。 这意味着，与Google Web Toolkit的情况一样，需要使用所使用的所有库的源代码来编译项目。 此外，这引起了有关新版本中对Java语言功能的支持的问题。 目前，开发人员承诺将支持Java 11的所有语法功能。
J2CL将不支持GWT窗口小部件，GWT RPC和其他GWT库-仅支持基本Java和JavaScript集成引擎JSInterop 。
即 这是GWT的非常有限的版本，带有全新的运输机。 并且，由于新产品不再与GWT兼容，因此称为GWT，而不是J2CL。 结果，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有一个很强的想法-将Java重用于前端，就像人们使用TypeScript一样。 另一方面，该项目似乎很晚。
JS中的新Transpiler项目（例如Kotlin.js和Scala.js）被实现为编译器插件，不需要重新解析源代码。 在这方面，J2CL是后退的，因为它需要它将解析的源代码。
另外一点是Java语言本身。 如果您可以用简洁的Kotlin编写服务器和客户端部分，为什么还要用冗长的Java编写？
尽管与另一个类似的项目JSweet相比 ，我更信任J2CL。 JSweet工具更加友好并且更易于使用，但是JSweet社区很小，几乎都是由一个人编写的。
你说开源代码吗？
当然很高兴该项目具有Apache 2.0的开放许可证。
不幸的是， 开源并不意味着开放的开发过程 。 社区最大的失望来自当前情况，J2CL项目是3年前宣布的，但是没有人显示其源代码，您无法影响其最终API并不能加快开发过程，因为没有地方可以发送补丁。
我们希望情况会有所改善，产品会变得可行。
更新：从GWT2移植的第一个J2CL应用程序-https: //github.com/DominoKit/dominodo