永利最大(官方)网站

      客户机代码必须与 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.这样简单就整合了这两个框架。怎么让那些老外想出来的？太有才了。有研究这方面内容的朋友可以参考的这篇文章 。这里就不重复了。感谢的技术分享。官方网站是：

部署 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 这一技术更有意思。