客户机代码必须与 Java 1.4 兼容。那意味着别指望在 GWT client-side 里使用类属性(泛型)、新样式的 for 循环等等5.0的新特征。

      在 GWT 客户端中只有极少的 Java 标准库受到支持。受支持的库类限于 java.util 包和 java.lang 包。但并不是所有这些包都支持。举例来说 Java.lang.reflect 包就不被支持（无法使用 Proxy, Method 等功能）。也就是说Java的反射机制在 GWT 的客户端中是不会通过编译的。（其实很容易考虑，你只要想想Javascript有没有这个功能。因为所有的 Client-side 的 Java 代码都将编译成 Javascript） 。对于序列化的客户机类也有一些限制，Java 的 Serialization 是不被支持的。该类可以通过实现接口com.google.gwt.user.client.rpc.IsSerializable 来实现。所有 JavaBean 必须继承 GWT 的序列化接口。(实现客户端与服务器端之间的 JavaBean 交互数据) 。因为 JavaScript 语言是不支持线程。所以在 GWT 编译程序中会忽略 synchronized 声明。当然，多线程的使用也别指望了。 也是不支持的。要使用 GWT.getTypeName(Object)才可以得到对象类型。GWT 允许自定义 Java-Javascript 编译器，如果你有兴趣可以研究一下。反正作到现在我觉得没那个必要。

      支持自定义控件库。做过 J2EE 客户端的朋友一定有这样的经验，喜欢把所有的 taglib 放入一个单独的 project 中。从而实现一个公司内部的 taglib 库，在以后的项目中我们可以重用这些 taglib. GWT 其实也可以这样的。但是你需要定义一个控件库的*.gwt.xml。并且在你的GWT项目的*.gwt.xml 中 inherits。
不可能将所有的服务器端接口合并为一个 Factory，
Example:

java 代码
public static Object getGWTService(Class service, String ServiceURI) {
Object instance = GWT.create(service);
ServiceDefTarget target = (ServiceDefTarget) instance;
target.setServiceEntryPoint(GWT.getModuleBaseURL() + ServiceURI);
return instance;
}

      这种方式是行不通的，我尝试了很久希望能够通过统一的接口来获得 RPC Service，可是当编译 Java to Javascript 时会报出 Only class literals may be used as arguments to GWT.create()的 Error message, 我的理解就是 GWT.create(..)中的参数不可以申明为一个变量的 interface class.可能在转换为 Javascript 时会出错。具体如何的内部机制无从考证。（这个 GWT 做得我都想哭了，我喜欢的设计方式都这样莫名其妙的被抹杀了）

      总之，以上为 GWT 客户端的限制，虽然有些麻烦，但是由于 GWT 客户端编译时要进行Java到Javascript之间的转换的原因，避免了你去开发那更烦人Javascript。而且这样一来可是使得客户端，服务器端的层次变得更清晰。因为我们无法把大量的逻辑代码写入客户端。层次的明晰使得维护，测试变得简便。总而言之，只要在客户端开发时注意我以上提到的这些注意事项，把大量的逻辑代码放入服务器端，你会发现其实 GWT 还是不错的！

整合 IOC 和 GWT

      用过 GWT 的朋友一定知道，要在 GWT 中定义一个 Remote service 就必须在*.gwt.xml 中定义这样一段 servlet 声明。可是这样的定义灵活性不够，而且无法做到将外部的 Java file 定义为 Servlet 项目中我们会希望使用 IOC 工具来实现 Remote service 的申明。并且实现把所有 Service 定义为外部 Jar（方便逻辑层的 Junit 测试）。这种方法不同于标准的 GWT 开发的，在此不是要提倡，只是提出另一种实现的方式而已。我在我的项目中就使用了IOC和GWT的整合。我要让GWT整合我公司内部开发的IOC工具，而且还要整合Spring和 Hivemind.这些流行的 IOC 工具（痛苦的过程），这里就不一一举例了。不过我要提一下 Spring 和 GWT 的整合。通过 Spring 的 DispatcherServlet 来分配 Server-side RPC servlet.这样简单就整合了这两个框架。怎么让那些老外想出来的？太有才了。有研究这方面内容的朋友可以参考的这篇文章 http://www.javaeye.com/topic/58084 。这里就不重复了。感谢的技术分享。官方网站是：http://gwt-widget.sourceforge.net/?q=node/39

部署 GWT 到 Tomcat 中

      在我研究 GWT 时，看到很多网站都有人提问如何在 Tomcat 中部署 GWT 。其实使用 Ant 打包 GWT 成一个 war file 再放入 Tomcat 中就可以了。我把我 GWTTest 项目中的build.xml文件发出来，有需要的朋友可以下载看一下，xml内有详细的注释。只要把 XML 中我打”*”号的部分改为你的 GWT 项目中相应的内容就可以直接使用 Ant 打包您的 GWT project 成 war 文件了。

Echo 和 GWT

      网上已经有非常详细的文章来比较这两个框架了。这里就不重复了，有兴趣的朋友可以一下。我之前也做过一个的项目，并且写了一篇的分析文章来介绍 Echo2。我这里就从一个开发人员的角度来简单的分析一下这两框架。其实从根本的底层技术上来讲，两者根本就没有可比性。GWT 是把客户端代码转换为 JAVASCRIPT，再使用 RPC 调用服务器端逻辑层 Servlet。而应该就是建立在 Servlet 上的一个框架，具体的核心实现方式我不了解。不过这两种技术都有一个共同点——太有才了。都是全的框架，而且你基本不用理那烦人的 JAVASCRIPT。视图层使用类似于 javascript 的编写方式就是最大的一个创新。从我个人的角度来说我更倾向于 GWT，因为 Echo 的性能实在有些不敢恭维(不过我相信如果未来的Echo3能够提升性能的话，Echo 会变得更出色)。

      看了一些 Javaeye 中其他关于 GWT 的文章。感到很多人是因为 GWT 有太多有别于一般意义上的 java 语言的特性才对 GWT 产生了一些误解。抱歉，我这里不是在针对谁，毕竟我相信除了 Google 之外很少会有公司运用这个框架来开发项目。很多技术如果不是在实际项目中运用，仅凭自学是很难深入了解的。当然我并不是说 GWT 有多好，他也有局限性。坦率说我更喜欢 wicket，个人觉得他融入了部分的 GWT 的客户端开发创意，而且很好的弥补了 GWT 中的一些不足之处。我喜欢这些有创意的开发理念，不断涌现的新创意会让 Java 这一技术更有意思。