譯者安：你敢大膽采用最新的技術嗎？你顧慮哪些方面？下面的采訪將給我們提供一個參考。
?原文：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程序員，那么你可以很快投入其中。