Does the GWT RPC system support the use of java.io.Serializable?

The GWT 1.4 RPC system does support the use of java.io.Serializable, however only under a certain condition.

Previous to 1.4, the GWT RPC mechanism used an "IsSerializable" marker interface for denoting classes that can be serialized. Many users expressed the wish to reuse code with GWT that they have already written that used the standard java.io.Serializable marker interface. Since both interfaces are empty marker interfaces, there is no technical reason why GWT's RPC mechanism could not use the standard java.io.Serializable. However, there are good reasons to choose not to do so:
  • The semantics of GWT's serialization are much less sophisticated than standard Java serialization, and so to use java.io.Serializable as the marker interface would imply that GWT's serialization system is capable of more than it actually is.
  • Conversely, GWT's serialization mechanism is simpler than standard Java's, and so to use java.io.Serializable would imply that users have more to worry about (such as serialization version IDs) than they actually do.
  • GWT implements only a subset of the full Java JRE classes, and specifically implements nothing in java.io. To use java.io.Serializable as the GWT RPC serialization marker interface dilutes the message that java.io is not usable within a GWT application.

While each of the points above still hold, the GWT Team felt that the community was generally aware of these issues but preferred the convenience of being able to use the standard java.io.Serializable interface rather than to have their classes implement the isSerializable marker interface. Considering this, the GWT Team made changes to the GWT RPC system to support the use of java.io.Serializable for data transfer objects (commonly referred to as DTOs) that would be transferred over the wire. However, there is one condition to enable support for java.io.Serializable in the new GWT RPC system.

RPC now generates a serialization policy file during GWT compilation. The serialization policy file contains a whitelist of allowed types which may be serialized. Its name is a strong hash name followed by .gwt.rpc. In order to enable support for java.io.Serializable, the types that your application will send over the wire must be included in the serialization policy whitelist. Also, the serialization policy file must be deployed to your web server as a public resource, accessible from a RemoteServiceServlet via ServletContext.getResource(). If it is not deployed properly, RPC will run in 1.3.3 compatibility mode and refuse to serialize types implementing java.io.Serializable.

Another important point to note is that none of the classes that implement java.io.Serializable in the full Java JRE implement java.io.Serializable in GWT's emulated JRE. What this means is that types that implement java.io.Serializable in the JRE like Throwable, or StackTraceElement won't be able to transfer across the wire through GWT RPC since the client won't be able to serialize/deserialize them. However, this isn't an issue for other types like String, Number, etc... that don't implement java.io.Serializable in the emulated JRE but have custom field serializers so that they can be properly serialized.

These differences between types that implement java.io.Serializable in the real and emulated JREs may be reconciled in a future version of GWT, but for the time this is an important point to keep in mind if your application uses GWT RPC.
Google apps
Main menu
2978103146873509222
true
Search Help Center
true
true
true
false
false