srcmini本文概述
GWT Web Toolkit(以前称为Google Web Toolkit)是一组开发工具, 用于使用Java编程语言来构建和优化基于浏览器的复杂应用程序。
GWT并非”还可以使用另一种Java工具编写Web应用程序”的事实是, 该工具箱的核心是将Java转换为JavaScript(以及HTML和CSS)的编译器, 从而使开发人员能够编写前端Web应用程序同时利用Java的所有优势。
GWT包含用于与Web平台接口的强大的互操作性架构, 因此甚至可以轻松混合使用Java和JavaScript。与Java本机接口(JNI)允许Java虚拟机(JVM)调用特定于平台的例程(例如, 访问特定的硬件功能或使用其他语言的外部库)类似, GWT允许我们编写大多数Java应用程序, 然后在必要时使用特定的Web API, 或者利用现有的JavaScript库进行”本地化”并跳入JavaScript。
GWT最初是Google产品, 但于2011年底毕业于开源软件, 如今已根据Apache许可(第2版)以GWT Open Source Project的名称发布。它由一个指导委员会管理, 该委员会由包括Google, RedHat, ArcBees, Vaadin和Sencha在内的多家公司的代表以及社区中的独立开发人员组成。
过去和未来的GWT
Google Web Toolkit于2006年首次发布。它是作为一种工具来帮助Google工程师开发其复杂的基于浏览器的应用程序, 例如AdWords, Google Wallet和Google Flights, 并且最近被用作Google表格和收件箱应用程序。
早在2006年, 浏览器(和JavaScript解释器)还远未标准化。前端代码运行缓慢, 有漏洞并且难以可靠使用。几乎完全缺乏用于Web开发的高质量库和框架。例如, jQuery直到今年才出现。因此, 为了能够开发大型Web应用程序, Google的工程师决定利用现有的工具和能力。 Java是满足他们需求的最合适的语言, 它广为人知并完美地集成到Eclipse等IDE中, 因此Google Web Toolkit诞生了。
目标或多或少地隐藏了浏览器之间的差异, 并封装了在Java编译器内编写高效JavaScript所需的技巧, 从而使开发人员摆脱了浏览器技术专横的束缚。
当然, 在过去的十年中, 网络已经发生了变化。浏览器已经变得越来越快, 并且已经收敛于实现标准, 并且已经开发了许多很棒的前端框架和库, 包括jQuery, Angular, Polymer和React。因此, 你可能会自然要问的第一个问题是：” GWT仍然有用吗？”
一句话：是的。
在现代Web开发的背景下, 针对浏览器是不可避免的, JavaScript已成为前端应用程序的通用语言。但是, 当然, 不同的工具和语言更适合于不同的任务。 GWT以及一些类似的项目旨在针对浏览器, 而不会限制开发人员使用JavaScript。
万维网联盟的所谓WebAssembly小组将在不久的将来为GWT之类的” Web编译”工具的开发和使用提供便利。不仅存在用于编译JavaScript的工具的广阔空间, 而且这种方法可以满足从卸载部分计算到浏览器, 重用现有代码和库, 在后端和前端之间共享代码的上下文中的实际需求。 , 利用现有的能力和工作流程, 并利用不同语言的功能(例如, 对于GWT, 使用静态类型)。
预计GWT项目将很快发布2.8版, 并且3.0版正在开发中, 并且工作上有很大的改进：
- 重塑了与JavaScript的互操作性
- 改进(几乎完全重写)的编译器
- 最新的Java支持(例如lambdas)
实际上, GWT 3.0的大多数功能已在公共Git存储库中提供。只需在此处签出主干, 并按照此处的文档编译GWT。
GWT社区
自2011年GWT开源以来, 社区一直在项目的发展中起着举足轻重的作用。
所有开发都在gwt.googlesource.com上托管的Git存储库上进行, 所有代码检查均在gwt-review.googlesource.com上完成。在这些页面上, 对工具包的开发感兴趣的任何人都可以做出贡献, 并查看社区正在开展的工作。在过去的几年中, 来自非Google员工的新补丁的比例已从2012年的5％上升至去年的25％, 这证实了参与度的提高。
今年, 该社区聚集在一起在美国和欧洲举行了几次大型会议。由Vaadin组织的GWT.create于1月在德国慕尼黑和加利福尼亚山景城举行, 有来自几十个国家的600多名参与者。 11月11日, 我们将在意大利佛罗伦萨举行第二版GWTcon, 这是我协助组织的社区推动的GWT会议。
GWT适合什么？
Vaadin发布的GWT工具包年度调查报告讨论了GWT的开发演变, 开发人员对工具包的看法, 优缺点。这项调查还使我们了解了Toolkit的用途, 用户社区的变化以及开发人员对Toolkit未来的期望。
你可以在此处找到《 2015年GWT的未来报告》, 这清楚地表明GWT在构建大型Web应用程序方面非常受欢迎。例如, 在第14页上指出：”大多数应用程序都是业务应用程序, 它们的数据量很大, 每天要使用多个小时。”
正如预期的那样, 很容易得出结论, GWT的自然环境是大型Web应用程序领域, 在该领域中代码的可维护性很重要, 并且大型团队会从Java语言的结构中受益。
另一方面, 查看GWT生成的代码的基准(例如, 在去年GWT.create会议的主题演讲中, 第7、8和11页), 很容易看到在性能和性能方面。代码大小, 编译后的JavaScript非常棒。如果正确使用, 则所获得的性能可与最佳手写JavaScript相媲美。结果, 使用GWT将Java库移植到Web上实际上是可行的。
这说明了GWT的另一个理想情况。 Java生态系统中充满了高质量的库, 而JavaScript中没有现成的对应库。 GWT编译器可用于使此类库适用于Web。换句话说, GWT使我们可以混合使用Java和JavaScript中可用的库, 并在浏览器中运行它们。
这种方法可以在PicShare的开发中看到, 我们展示了如何使用GWT将几个通常不用于Web的Java库(例如, NyARToolkit)移植到浏览器中, 并与包括WebRTC和WebGL在内的Web API结合使用, 以实现以下目的：获得完全基于网络的增强现实工具。我很荣幸能在去年1月的2015 GWT.create会议上介绍PicShare。
具有Java应用程序功能的JavaScript前端？是的, 使用GWT, 你也可以拥有全部！
鸣叫
幕后花絮：将Java变成JavaScript
GWT工具包是一组相当复杂的工具, 但是由于与Eclipse的易于使用的惊人集成, 任何人都可以轻而易举地使用它。
对于具有Java开发项目背景的任何人来说, 使用GWT创建简单的应用程序都相对容易。但是, 要了解”实际情况”, 值得分析该工具包的主要组成部分：
- Java到JavaScript Transpiler
- 模拟Java运行时环境
- 互操作层
GWT的优化编译器
关于编译器如何工作的深入描述在很早以前就变得技术性很强, 我们不需要对此进行深入研究, 但是一些常规概念值得一看。
首先要了解的是, GWT通过在源代码级别进行翻译将Java编译为JavaScript。即, 将Java源代码翻译(译为技术术语)成JavaScript。这与使用JavaScript编写某种Java虚拟机来执行Java字节码相反。 (这实际上是可能的, 并且是Doppio使用的方法, 但GWT并非如此。)
取而代之的是, 将Java代码分解为代表代码句法元素的抽象语法树(AST)。然后将其映射到等效的(和优化的)Javascript AST, 最后将其转换回实际的JavaScript代码。
权衡翻译的优缺点远非本文的目的, 但让我观察到, 通过这种方法, GWT可以直接利用JavaScript解释器的垃圾收集服务以及浏览器本身的任何其他功能。
当然, 有一些棘手的部分。例如, JavaScript只有一种数字类型, 不能包含Java的64位长整数类型, 因此长类型需要编译器进行特殊处理。另外, Java静态类型在JavaScript中没有直接含义, 因此必须格外小心, 例如在转换后保持类型转换操作等效。
另一方面, 易于理解的编译优势是GWT可以在Java级别和JavaScript级别执行优化(在大小和性能方面)。生成的标准JavaScript代码甚至可以在你的部署管道中进一步处理。例如, 现已集成到标准GWT发行版中的一种常见做法是, 使用高度专业化的JavaScript到JavaScript Closure编译器(Google众神的另一项礼物)来优化编译器的JavaScript输出。
我知道的有关GWT编译器的最深入的描述可以在本幻灯片中找到, 以及它的原始论述。在这里, 你可以找到有关编译过程中其他出色功能的详细信息, 例如GWT的代码拆分功能, 生成多个单独的脚本文件以由浏览器独立加载的功能。
模拟的JRE
如果不通过Java Runtime Environment(JRE)的实现加以补充, 则Java-to-JavaScript编译器将仅仅是新颖, 它提供了几乎所有Java应用程序所依赖的核心库。粗略地说, 使用Java(例如没有Collections或String方法)进行工作会令人沮丧, 当然, 移植这些库是一项艰巨的工作。 GWT通过所谓的”仿真JRE”填补了这个漏洞。
模拟JRE绝不是Java JRE的完全重新实现, 而只是一种对客户端有用(和可用)的类和方法的选择。 Java JRE中的功能, 但在仿真JRE中找不到的功能可分为三类：
-
无法移植到客户端的内容。例如, 无法在浏览器中以与Java相同的语义实现java.lang.Thread或java.io.File。浏览器页面是单线程的, 无法直接访问文件系统。
-
可以实施但会在代码大小, 性能或依赖性方面”花费太多”的事情, 因此社区不希望在GWT内部使用。例如, 此类别中包括Java反射(java.lang.reflect), 它将要求编译器保留每种类型的类信息, 这将导致已编译JavaScript的大小膨胀。
-
没有人感兴趣的事情, 因此尚未实现。
如果碰巧Emulated JRE不能满足你的需求(例如, 你需要一些未提供的类), 则GWT允许你编写自己的实现。通过标签<super-source>可用的这种强大的机制可以在改编使用未仿真的JRE的新外部库时规避问题。
提供JRE某些部分的完整实现可能过于复杂, 甚至是不可能的, 因此对于特定任务, 你自己的实现可能并不严格遵循Java JRE的语义, 即使它们在你的特定情况下也可以使用。确实, 如果你正在考虑将类归还给项目, 请记住, 对于仿真JRE而言, 至关重要的是, 所包含的每个类都遵循原始Java JRE的相同语义。这样可以确保任何人都可以将Java代码重新编译为JavaScript, 并相信他们将获得预期的结果。在将其返回给社区之前, 请始终确保对你的代码进行了全面的测试。
互操作层
为了成为生产实际Web应用程序的有效工具, GWT必须允许开发人员轻松与基础平台进行交互。即, 浏览器和DOM。
从一开始, 就构建了GWT以通过JavaScript本机接口(JSNI)支持这种交互, 这使得浏览器内API的访问变得轻而易举。例如, 使用GWT编译器独有的语法功能, 你可以编写以下Java代码：
public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{
//place your JavaScript code here
}-*/;
并且你可以自由地在JavaScript中实现方法的主体。你甚至可以将JavaScript对象包装在JavaScriptObject(JSO)中, 并使其在Java代码中可访问。
在UI组合的上下文中可以找到该层起作用的示例。主流Java一直使用标准的Widgets工具箱来构建UI元素, 利用Java Native Interface来访问底层操作系统的窗口和输入系统。 GWT的互操作性层也做同样的事情, 因此传统的Widget在浏览器中可以无缝运行。唯一的区别是, 在这种情况下, 底层系统是浏览器和DOM。
但是, 近年来, 本地前端框架得到了快速改善, 如今, 与GWT的Widgets相比, 它们具有明显的优势。随着这些框架的日益成熟, 试图在JSNI中实现它们的尝试暴露了互操作性层体系结构的不足。从2.7版开始, GWT引入了JsInterop, 这是一种基于Java注释的新方法, 它使你可以快速轻松地将GWT类与JavaScript集成。不再需要编写JSNI方法或JSO类。相反, 你可以简单地使用诸如@JSType或@JSProperty之类的注释, 从而使你可以像对待Java一样处理本机JavaScript类。
JsInterop的完整规范仍在进行中, 只能通过编译来自GWT存储库的源代码来试用最新更新。但是已经很清楚, 这就是新的方向, 它将使GWT能够跟上不断发展的Web平台。
最近发布的gwt-polymer-elements是利用JsInterop进行的一项正在进行的项目, 该项目将Polymer的所有铁和纸元素提供给GWT。该库中有趣的是, 开发人员无需手动生成Java API。该项目使用gwt-api-generator通过解析Polymer库和JSDoc批注直接生成大多数接口。这样可以很容易地使绑定保持最新。
最后的话
随着过去两年对编译器, 互操作性层以及所生成代码的性能和大小的改进, 很明显, GWT不仅是”另一个Web开发工具”, 而且有望成为其主要参考工具箱。开发大型, 复杂的Web应用程序, 甚至可能是使更简单的应用程序变得如此出色的绝佳选择。
我每天都会在GWT中担任开发人员和顾问, 但是我最喜欢GWT, 因为它使我能够突破浏览器功能的极限, 并表明现代Web应用程序可以像桌面应用程序一样强大。
GWT项目的社区真的很活跃, 并且不断提出基于GWT的新库, 项目和应用程序。在佛罗伦萨, 由社区推动的GWTcon2015将于11月11日举行会议。如果你在该地区, 我希望你能与一些核心开发人员会面, 并了解成为该惊人工具包演变一部分的所有机会。
评论前必须登录！
注册