Should a GWT-RPC service use java.io.Serializable as a parameter type?

I am defining a simple "key-value store" service in GWT; I will be writing the server but letting others write clients so it should be as simple as possible. I want the client to be able to use String keys, but values of any serializable type. So I defined the interface:

public void put(String key, java.io.Serializable value);
public java.io.Serializable get(String key);

This works perfectly, but there's one problem: Eclipse gives the following warning on both methods:

Checking all subtypes of Object which qualify for serialization

Googling that warning, it seems like GWT is going to generate a piece of code for every single type in the program. Therefore, this could be quite expensive. I'm confused because I thought that all types开发者_开发技巧 in the Serializable interface already had serialisation code, and it could just call that (but perhaps that serialisation code is only generated in this case).

So I have a number of questions:

• Is this going to make the client code much a) bigger and/or b) slower? How serious is that problem?
• I see GWT provides a separate interface IsSerializable. Can I use that instead? I tried it but I noticed that basic classes like String and Integer do not implement this interface.
• If I make the RPC layer use byte[] instead, but provide a wrapper method for my clients to serialize a java.io.Serializable into a byte[], will that get around the problem, or will it end up with the same code bloat problem I started with?
• Is there a better way to implement a key-value store which allows arbitrary-type values without too much work on behalf of the client?
• If I stick with Serializable, is there a way to suppress that warning?

I see GWT provides a separate interface IsSerializable. Can I use that instead? I tried it but I noticed that basic classes like String and Integer do not implement this interface.

Yes. IsSerializable is preferred over java.io.Serializable. The GWT FAQ lists the reasons why this is 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.

>

If I make the RPC layer use byte[] instead, but provide a wrapper method for my clients to serialize a java.io.Serializable into a byte[], will that get around the problem, or will it end up with the same code bloat problem I started with?

Bad idea. In this case, the serialization from objects to byte[] will happen in JavaScript on the client side. Yes, serialization is possible on the client side, but with the GWT protocol; that's not Java serialization. The browser will not do that well.

Is there a better way to implement a key-value store which allows arbitrary-type values without too much work on behalf of the client?

Unfortunately, I think you will not be able to get away with one true method for all classes. I suggest you try the following interface:

interface Store<T extends Serializable & IsSerializable> {
void put(String key, String value);
void put(String key, Number value);
void put(String key, T value);

Integer getInt(String key);
Double getDouble(String key);
BigDecimal getBigDecimal(String key);
String getString(String key);
IsSerializable get(String key);
}

The generics ensure that the object has both interfaces, so that you can serialize then both with the GWT protocol (from client to server) and Java serialization (from server to data store).

Edit Answering comments:

With that last solution, doesn't the generic mean the store can only store a single type of object, and if the client wants to store a different one, he has to create a new store?

Yes, the client would have to create a new store for each type. If it really bothers you, A solution around this is to create a new interface MySerializable, which extends IsSerializable and java.io.Serializable; but then each object will have to implement that, which creates a dependency on your project.

Also doesn't it require that the object is both Serializable and IsSerializable?

Yes, and that's a benefit. Otherwise, you risk having an object on the server side that is not java.io.Serializable; if you try to supply it to method ObjectOutputStream#writeObject, an exception will blow up at your face.

Lastly, what about my first question: is just using io.Serializable actually going to affect the code size / performance?

I cannot say that from real usage, but I don't think so: both are simply marker interfaces. The GWT serialization will be the same for either.