译者安：你敢大胆采用最新的技术吗？你顾虑哪些方面？下面的采访将给我们提供一个参考。
原文：Interview: Real-world Experience with Google Web Toolkit (GWT)
在java中，对技术的采用是一件让人心烦的事情，因为我们获得通知的途径太多。不同的会议，不同的站点如slashdot和theserverside,而且还有数不清的个人博客如dhh和o'Reilly's Radar.
一个让人感兴趣的技术总是让业界议论纷纷，正如人们所意识到的，这个产品并不是成熟期。
为了让一个产品成为主流，早期的采用者必须足够喜欢这项产品来承担很多非常的任务以便
让更为胆怯的开发者相信这项新技术值得采用。像Hibernate和Spring Framework这样的技术花了好几年
才成为一个成熟产品。许多产品，比如maven,在版本确定之前经历了痛苦的时期因为他们早期缺乏
足够的文档或者有不同的足够强大的挑战者比如ant.本人对这个过程中的盲点很感兴趣，从议论这个产品的介绍到大范围的采用往往要经历成月上年，而且很难指定时间表。hibernate并不是暴雨似的到来,而是通过大量用户自我采用.一个失败的项目比如ojb出来的时候也是引起轰动,但是它最终没有承诺的那么好.在这种情况下,早期的hibernate使用者其实信心不足.
让我们来看Google Web Toolkit (GWT)…
GWT在这个进程中处于什么位置？
gwt看起来是在早期使用（early-adopter）的中期。一开始的议论声已经消去，现在陆续出现了许多关于gwt的文章和博客，表明了人们正在期待关于gwt的第一个helloworld的反馈报告。我的很多谨慎的同行都在回避他，事实上认为它是个不好的主意。风险阻碍了开发者对大多数新技术的评估直到他们在现实中看到了一个活生生的实例解决方案--就像maven被ibm使用一样。那些有能力来尝试风险的开发者正在对这个框架进行测试。他们中的某一个或许宣称gwt不适合它的组织。另外一个同行已经原则上接受了gwt的观点，但是没有时间来在他的应用中集成。所以，到底gwt处于什么时期？早期的使用人群有哪些经验呢？
关于这个问题，我专门采访了Grassroots Technologies公司的Michael Podrazik。Grassroots Technologies是一个在纽约的咨询小组。通过在Grassroots的工作，michael已经正在把gwt应用在他们的一个新的正在开发的web应用当中。在下面的采访里面，我要求他来交流他的产品经验来帮助其他人去理解gwt.我特别要求他给一些gwt客观的意见,而且细致的描述他在用gwt开发过程中遇到的挑战。幸运的是，他的信息将会帮助你决定是否gwt是你项目的正确选择。
采访内容：
q:什么使你选择了gwt?
a:我订阅了google的blog,所以我听说了gwt当他发布到javaone的时候。在阅读了他的文档之后我开始对这种方式很好奇，因此我把它down了下来而且开始使用它(play with it).我刚刚开始了一个项目，这个项目是把遗留的 Access/VBA的桌面应用升级为一个web应用。在UI方面有许多ajaxian特性所以我想我可以让gwt一展身手。我认为（figure）只要我保持我的架构足够抽象，我就有能力用更为传统的web应用框架来替换gwt层。gwt会很伤脑筋吗？至少目前为止我很开心。
q:gwt出现了那些挑战？你围绕着gwt设计的web框架吗？gwt是否挑战了你关于web应用开发的观点？
a:你确实不能简单的认为gwt是一个webapp的框架，他更是一个有着rpc和对象序列化的ui类库。因为你需要改变你项目组织的assumptions以及包的结构。在java服务端开发rich-client用户界面我们有大量的经验，比如flash/actionscript.gwt和他们十分类似，因此可以想象有这些元素的项目--分隔的服务端和客户端而不是同一的webapp--很爽。
朝着这个方向，你需要明确区分服务端和客户端的功能。我相信一个好的哲学就是使你的客户端仅仅用于展示。
你需要思考你服务接口的设计，比如每个操作的粒度
你不能在客户端代码上用java5得语法
Q:你的意思是不能再gwt的具体类或者普通的web应用里面用java5的语法？
a:你不能在客户代码里面使用java5的语法。我们在服务端代码中使用了许多java5的特性，但是所有将要被转换成javascript的代码必须是1.4的规范。
这个也包括许多事实上你用在服务端的类。因为rpc框架允许用户定义的数据类型的序列化，意思是你将在浏览器端得到一个已经被转化为javascript实例的类，这个类作为一个参数传递到服务端的实现中。在你的服务端代码中，你将操纵同一个class而且是编译过的字节码。
这个时候就出现了一个选择，domain module和gwt的耦合度怎样才合适呢？
What we decided was to keep value objects implementation-agnostic so as to avoid “infecting” the API and persistence layers with beans implementing GWT’s IsSerializable interface.
举个例子，在服务端我们有个IUser接口的用户模块，这个借口继承自IPersistable.gwt的实现接受和返回实现IsSerializable接口的GwtUser的实例并把这些实例利用commons-beanutils发送到服务端。
对于这一点可能有些争论，这样做并不非必要。但是我觉得这点额外的工作将带给你更为清晰的层次划分。我们可以嵌入gwt到任何一点，而且可以转换到springmvc或者struct或者其他的地方，而不需要担心代码上 的反应。
q:你发现gwt产生的javascript不能垮浏览器的地方了吗？你发现gwt产生的javascript包含一些错误需要手动调试了吗？
a:都没有，这正是令我们惊讶的地方。跨浏览器javascript的开发是PITA，而且GWT真正的把你从他那里隔离开来。
我发现了大量的在FIREFOX和IE不同的地方，但是这些最后被确认都是CSS支持的问题而于GWT无关。
我也遇到了一大队JAVASCRIPT错误，但是这些错误都是应为变量而不在初始化，这些问题很快就会找到并且不需要大量的调试。目前已经完成的大多数工作并不全是ui控件的问题，或许随着我们的深入，我们会遇到一些问题，但是目前为止，我们还没有多少麻烦。
q:你的工作组的成员是更喜欢java还是javascript呢？
显然是java,哈哈。但是我们有人对javascript和actionscript也很精通。就像译者本人。
q:一句话，对正在考虑gwt的人，你有什么建议？你会推荐他吗？你对这项技术的客观观点是什么？thumbs up or thumbs down?
a:目前是thumbs up.我们目前仍然在开发的早期，而且我还不想说在它是完美的或者在以后的进程中不会咬我们一口。意思是说，你的建构要搭好。 它真的像是在作swing或者其他UI的桌面应用。
我们用基于Controller和IView实现的GWT生成了全部的ui.除了gwt模块引入以外，那里没有html。
这是对几乎所有主流web应用范例的违背，但是如果你喜欢ui编程，他完美的抽象了ajax/dhtml的行为到一个十分友好和可扩展的api.
我或许会说如果你的工作是php,asp或者其他语言，你或许需要花更多的功夫。如果你已经是一个有经验的java程序员，那么你可以很快投入其中。