百度网站怎么做信息,微信小程序开发技术栈,wordpress错误怎么解决,开发公司账务处理上周#xff0c;Google团队终于发布了J2CL框架的源代码#xff0c;自2015年以来就对此进行了讨论。将Java转换为JavaScript的想法根本不是什么新鲜事#xff0c;而且每个人在使用Google Web Toolkit之前都遇到了麻烦该产品在社区中倍受关注-经过讨论并成为会议演讲的主题Google团队终于发布了J2CL框架的源代码自2015年以来就对此进行了讨论。将Java转换为JavaScript的想法根本不是什么新鲜事而且每个人在使用Google Web Toolkit之前都遇到了麻烦该产品在社区中倍受关注-经过讨论并成为会议演讲的主题但没人能看到它 。 自首次发布以来已经有3年多了而且该产品似乎甚至在其诞生之前就失去了市场。 今天我们有了Scala.jsKotlin.js和JSweet此外该开发已经由TypeScript占用并且Java不再有地方了。 这么长时间以来即使是最热爱Java的人也对“ Java for Front end”失去了信心并学到了一些JavaScript框架。 但是由于它终于发布了所以让我们看一下结果以及将其用于什么目的。 理念 在全球范围内在浏览器中模拟JVM是一项相当复杂的任务。 Google Web Toolkit开发人员长期以来一直在尝试解决此问题并取得了一定的成功他们建立了一个编译器开发了标准的Java库仿真机制为应用程序开发提供了工具。 这种方法具有许多优点静态类型检查浏览器中服务器代码的可重用性以Java IDE表示的现成工具。 现在TypeScriptWeb 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双向交互的方式但该框架无法摆脱UIRPC库和其他应用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
