我是QCon的Scott, 今天和我一起的是Bruce Johnson，Google Web Toolkit的技术领导。Bruce，跟我们讲讲你和你的团队为什么选择将创建GWT作为起步？

简洁的说，基本上最初是试图寻找一点额外的方法来管理这个庞大的AJAX代码库。JavaScript语言非常强大，在小范围内它的弹性是件好事，但一旦有越来越多的人加入并工作于同一个代码库的时候，一些依赖于纯粹的规则以及一贯使用的习惯用语的东西开始变得难以管理，这就导致我们卷入到所有东西搅和在一起无法理清条理的“意面”的困境中，我们开始试问难道没有办法提供更结构化的东西，这时我们想到这个将Java翻译成JavaScript从而借用Java来提供一点结构的点子。

请你讲一下选择Java作为开发语言然后开发AJAX应用程序的优点是什么。

Java是强类型语言，这点很好。无论是静态还是动态类型语言，都各有各的优缺点，但是从静态类型语言编译肯定有它的优势－－其中一点就是，在java源码中可以检查很多在JavaScript中无法真正检查的东西。使用Java，你可以简单地通过JAR共享代码，而在JavaScript中就更需要一点小窍门，没有那么精巧的复用模式。我们希望鼓励大家使用好的软件工程实践模式，复用是其中极为重要的一个部分。而且，你有各种各样的Java工具可供使用，比如像优秀的Java集成开发环境Eclipse、IntelliJ iDEA、NetBeans等等。对于GWT而言，由于它同样与Java源码结合工作，所以它也隐性工作于所有这些开发环境。在此基础上，我们又进一步确保它同时也能工作于java标准调试器、java调优器、代码覆盖工具、类似于FindBugs这样的静态分析工具等等。所以，单是简单的转化开发语言，我们已经是获益匪浅。

由于这整个从Java到JavaScript的编译过程的存在，有些人最初认为对于GWT不存在真正意义上的编译器。对于这个问题你会如何回答，或者能否给予那些并不完全理解这个技术背后蕴含的人们一点启示？

我猜想人们的第一印象也许会是：“这是个某种意义上的翻译器”。在看到表层之下它究竟如何工作以后，他们会发现这样的印象就有点小觑了这项技术。他们设想我们只是以某种方式盲目地将一个特定的Java结构翻译成JavaScript，以致于会产生冗Bruce Johnson:余代码等一些问题。实际上，我们采用一种更计算机科学、更强有力的方式，那就是，我们将所有的Java源码聚合做语法解析，在此基础上再做优化处理。我们有目的地禁止反射机制和动态类加载。这样做的好处在于，在知道所有源码都可以通过编译器进行分析的前提下，你可以对程序作整体优化。反射机制会影响完全静态分析的实现，因为在运行时之前，你永远都没有办法知道会发生什么。但如果你剃掉了这个因素，你可以编译一个巨大的Java源码库，并且如果你将整个源码库作为一个整体编译，你甚至可以分析每一处调用，每一个方法的具体实现。

你可以鉴别出那些看似多态性实际上却不是的部分，我们将它们称为“type tightening”。一旦作了type tightening，其实就已经消除了多态机制，并且一旦重写调用点并将多态分派翻译至静态分派，你就可以内联源码，这样做允许你迭代另外的优化处理。所以说它是真真实实的编译器，我刚才提到的优化实在只是冰山一角，在未来我们将可以做更多更酷的优化。GWT使用者得到的好处是，他们所需要做的只是升级GWT版本，重新编译而已，他们将在文件大小或速度或两者同时获得巨益。比如在即将发布的GWT1.4中，一个简单的重编译可以将文件大小减小20%并能够更快地启动。

你们在去年近年底的时候发表了一篇文章叫作：“Making GWT Better”。那么，文章中提到各个方面是怎样驱动GWT的演化的呢？

我们是在十二月份开放源代码的时候做的这件事情，我们其实只是想确认我们启动开放源码社区是迈出的正确一步。所以在“Making GWT Better”这篇文章中，我们所做的是列出一些大家可能无法一目了然的GWT表层之下蕴藏的原理。当你听到“GWT”时，你可能将它设想成只是关于从整个平台中提取信息的过程，或只是为了方便代码的编写而甚至不惜在速度或文件大小上付出昂贵的代价。事实上，这根本是误解，我们阐述的目的更多的在于终端用户体验，在文章中也解释了相对于什么更酷、什么对开发者来说更方便的论题，我们更看重用户体验。

我们在跟开发者在线讨论时候时常会遇到开发者说如果可以实现X，Y或者Z，那么会使得开发更容易得心应手，但如果我们真的决定那样去做的话，就会从某种方式上对终端用户体验造成消极影响，所以，我们基本上是不会那样去做的。我们将终端用户体验置于开发体验之上。如果我们可以找到一些方法使得开发更简单的话，我们显然一定也会设法将它实现。我们最喜欢的特性是那些能够将你的应用程序变得更小、运行更快、更有用并且使用非常方便的特性。通过实现GWT很多核心工具，我们实际上已经达到了这个目标，这些工具有：History，RPC，JSNI等等。

完全开源之后，你们是怎样将GWT推向社区的呢？据我所知，开发人员在面对一件事情的时候总是很谨慎，那就是这个项目究竟是一个人的还是一个公司的？社团又是怎样交互的呢？

Bruce Johnson:我们真得非常高兴。我们已经从很多人那里得到各种非常精彩的点子，他们遍布世界各地，就此我们也已经提交了许多许多patch。我们有两个邮件列表/Google group：第一个是传统的GWT用户论坛，论坛里的人们看到我们开源都非常得振奋。他们感兴趣于查看他们一直在用的工具究竟是怎样实现的，更重要的是因为只有当他们了解了代码他们才觉得能更自在地使用GWT。就算Google通过某种方式抛弃GWT，他们仍然能够继续使用GWT，当然像抛弃这样的事是不会发生的。事实上，我们正在扩建我们的GWT团队，所以抛弃GWT当然不会是发展的方向，但是我猜想手中握有代码队大家来说能感到安心一些。除此之外，还有一个组叫作GWT-contributors，在这个组中我们讨论每个新版本开发的具体细节，而且在过去的8-10个星期里，我们已经有上百个人注册，也已经有一些非常精彩的关于有趣且深刻的GWT底层技术的讨论。这着实很棒。

你们几个月前才发布1.3现在又马上要发布1.4，在1.4中主要的特性是什么？刚才你只是谈及编译文件的缩减，你是否能跟我们再讲讲其它一些新特性？

Bruce Johnson:这些新特性中有很多我真的很喜欢。在internationalization库中，我们补充加入了日期时间和数字的格式化/解析（formatting/parsing），其实一直以来我们就很需要这样的功能，现在终于能够在1.4中推出。另外还有不依赖于编译器的启动时间优化，比方说在你重新启动以前已经下载的应用程序的时候，启动过程中你实际所读取的比特数比以前减少了80％，因此启动更快并占用更小的带宽。另外一些大的东西是：1.4中有一个基准测试子系统，这个子系统将工作于JUnit上下文中，但实际上它只对你当前所选代码起作用。所以你完全可以通过自动生成数据表和图表来查看一些源码的行为表现，这非常实用，因为根据你所使用的底层JavaScript方法，同一段代码跨浏览器会有很多很不同的行为表现，所以这是一个很不错的方法使得我们能够确信我们正在底层做一些非常有效力的事情。

此外，我们还新增了一些重要的widget：带有拼写检查的富文本（Rich Text）；自动提示文本框（AutoSuggest text box）；一些按钮的变异（button variation），比如像图像按钮、自定义按钮、锁钉按钮等等。另外有一个我觉得非比寻常并且非常强大的一个特性叫作ImageBundle。我们实际上对一个GWT应用程序发送的HTTP请求进行计数－－我们择取实际正在工作的应用程序，统计其HTTP请求数，然后决定“我们能否剔除某个请求”，我们反复进行这样的操作。我们注意到一个常见的用例是创建一个工具栏或者某种使用很多图像的东西，在一个大的应用程序中你可能最终会请求成打成打的小图像，即使响应内容基本上“没有改变”，你仍然需要建立那些连接并且关闭那些连接，因为流出的（outgoing ）HTTP受限同时只能有两个连接，这导致了根本不做任何事情的socket之间发生竞夺。

这时你才发现拥有的图像已经是最近的，这些连接是一种浪费。所以现在我们在编译时做这件事情，如果你想要创建的是ImageBundle并涉及一些不同的图像，我们会在编译时读取这些图像，将它们合成一个以唯一的名字命名的大的图像文件，这样一来可以在客户端将它们缓存起来，然后用一个相似的结构模拟图像来替代对那些图像个体的引用，这个结构其实只是一个从大的组合图像中的修剪下来的矩形。所以尽管你可能要下载40个图像，但现在只需要下载一个，你所需要的不同图像对象只是这个大图像的不同部分。这样极为有趣的技术是我们拥有这个编译步骤之后的直接产物。