Treat java.io.Serializable as being equivalent to IsSerializable

[Miguel Méndez]

Hello GWT Users and GWT Contributors,

[ If you have no interest in GWT-RPC you can stop reading now. ]

Issue 21, "Lack of java.io.Serializable hurts interoperability" has received a lot of interest.  46 people have starred it and we have spent a considerable amount of time discussing it and related topics on various threads.  In a nutshell, it seems that most people are in favor of adding java.io.Serializable for the purposes of interoperability and some people even suggest that we use it as the serialization marker instead of GWT's IsSerializable.  I wanted to get a little more feedback before we make the final decision on this issue for the 1.4 release.

Original rational for not supporting java.io.Serialzable
Let me start by saying that I originally opposed adding java.io.Serializable to GWT for the following reasons:

java.io.Serializable is a protocol, not just an interface - It dictates the mechanics and infrastructure required to serialize and deserialized a type.  This protocol does not necessarily make sense for GWT-RPC since we do not need full blown persistence, just a lightweight marshaling between the client and the server.

• Java object construction during deserialization

When java deserializes an object that implements java.io.Serializable, it essentially allocates an object but instead of calling the default constructor for the concrete type, it searches up the inheritance hierarchy to find the first non-serializable class and calls the default constructor on it.  Then it proceeds to deserialize the type.  Unless we want to match this behavior, we will need to only allow classes that have default constructors.

• serialVersionUID

Java's serialVersionUID carries compatibility semantics that we do not currently have a way of supporting.

Adding java.io.Serializable does not address the next set of interoperability issues that developers will encounter. 

• Java custom serialization

If you have a POJO which implements java.io.Serializable which also uses some form of custom serialization, by implementing any of the implicit methods that make up the java.io.Serializable protocol:

• private void writeObject(java.io.ObjectOutputStream out)
          throws IOException;

• private void readObject(java.io.ObjectInputStream in)
          throws IOException, ClassNotFoundException;

• Object writeReplace() throws ObjectStreamException;

• Object readResolve() throws ObjectStreamException;

your type still will not be usable because it will fail to translate due to ObjectInputStream, ObjectOutputStream, and ObjectStreamException.  If we added these types, the implementation of the serialization methods must still be translatable, etc.  If the methods were translatable the special serialization logic that they implement still would not be used by GWT.

• ORM's that return subtypes

If you are using an ORM solution, like Hibernate, it can legally return the subtype of a declared type.  For example, it will return a java.sql.Date in place of any java.util.Date.  This seems like another problem on the interoperability frontier.  Granted, this could be addressed by adding support for java.sql.Date but the more general problem is one of type-mapping, where the ORM layer maps a given type onto a subtype not known by the client code.

Proposal:
Given all of the reasons for not supporting java.io.Serializable, it still seems like there maybe a useful partial.  Would it be valuable if, starting with the 1.4 release, we make java.io.Serializable equivalent to GWT's IsSerializable?  This would allow GWT to send objects across RPC if they implement java.io.Serializable or IsSerializable, and are default constructable.  We are considering tighter integration stories for subsequent releases but for now we need to constrain the discussion to what can be done for 1.4.

Pros:
People who have classes that use Java's built-in serialization, that do not implement any of the readObject, writeObject, writeReplace or readResolve methods, that also have no-arg constructors will be able to use their objects, as-is, without any DTOs.

Cons:
If you are using any form of custom serialization via the implicit java.io.Serializable methods or if you are running into a ORM subtype problem, you will still need to use a DTO type solution.

Are there enough people who would be served by this constrained support for java.io.Serializable to make it worthwhile?  Or are there a large number of people who would still run into the next set of interoperability issues?

Feedback welcome,

--
Miguel

[Sandy McArthur]

I'm not going to claim to have a majority view here but I don't mind
that Serializable and IsSerializable are not equivalent.

I want to be able to have my GWT client code implement
java.io.Serializable (and you can do that with GWTx added to your
project) but it doesn't bother me much that I need to also implement
IsSerializable. I'd just like to have Serializable emulated in the
stock GWT libs so I can compile code that implements Serializable.

My usage is I have a POJO which I want to send between the server and
browser via GWT's RPC, and I want to be able to stuff an instance of
that POJO into the user's servlet session in a clustered webapp. (To
replicate sessions on the server all objects added to the session need
to implement Serializable.)

That said, as the maintainer of GWTx, every other month I get an email
similar to "I added GWTx to my project and my class implements
Serializable but it doesn't work with RPC." Which is unfortunate
because if you include a java.io.Serializable that doesn't let an
object be sent via RPC you'll start getting support requests like
that.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

[Ian Petersen]

I'd like to vote for adding java.io.Serializable to GWT and, in the
future, using it to completely replace IsSerializable.

As I understand it, the main reason that java.io.Serializable is not
already the serializable marker for GWT is that GWT either cannot or
does not need to implement all of the java.io.Serializable contract.
In particular, writeObject, readObject, writeReplace, and readResolve
are difficult or impossible to implement in GWT.

I'd like to suggest a possible solution. What if the GWT compiler
explicitly ignored the four problematic methods (writeObject and
friends)? GWT's RPC mechanism already supports customized
serialization through the policy of looking for a
_CustomFieldSerializer class that parallels the serializable class.
If a given serializable type needs to have control over its
serialization process, it can control this process in a manner
appropriate to each environment in which it will be serialized
(regular Java serialization and the GWT-specific version).

The main reason I think my suggested approach will benefit GWT and its
users is that base classes could be marked java.io.Serializable and a
lot of code can be re-used for both client- and server-side
programming. The difficulties faced by people using ORMs will persist
no matter what the GWT developers do. Also, every aspect of GWT is
"tainted" by the fact that the runtime environment of a GWT
application is _not_ Java. The fact that GWT can't or won't support
the versioning features of serialVersionUID is irrelevant to me--the
runtime environment is different, so a whole host of assumptions that
are valid in a JVM are invalid in a browser and adding
serialVersionUID to list of broken assumptions is really not a big
deal. I think the marginal pain caused by one more broken assumption
is much smaller than the marginal gain of permitting the re-use of
classes marked by java.io.Serializable.

The reason I think IsSerializable should eventually be dropped again
has to do with re-use of base classes. I'd prefer that my server-side
code is mostly unaware of GWT (obviously the servlets responding to
GWT RPC requests have to be aware of GWT). Forcing serializable types
to implement a GWT-specific interface make this separation of concerns
more difficult to achieve.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Jason Essington]

+1 for adding java.io.Serializable as a peer to IsSerializable in GWT.

It seems that supporting Serializable as a peer to IsSerializable
would be the fist step in solving most of the RPC problems that are
seen on the list.

Besides the problems mentioned, there is the issue of using
Annotations on your persistent objects. Currently they cause the GWT
Compiler to choke and die.
Also, depending upon how GWT attempts to serialize an object, lazy
loading may be a bit of an issue.

BUT, supporting Serializable on the client with the caveat that the
entire implied contract of the java version cannot be upheld would at
least get one of the stumbling blocks of RPC serialization out of the
way.

-jason

[theClassConnection]

+1 for totally replacing IsSerializable with java.io.Serializable...
(eventually... I actually really like the Serializable=IsSerializable
proposal, though I don't see any reason to keep IsSerializable on much
longer...)

I can only speak for my project, but we've had to deal with creating
duplicate classes 3 separate times to get around the inability to
compile Serializable and the IsSerializable requirement. (One class
is the client-side version that implements IsSerializable, one the
server version that implements Serializable, where you can generate a
client-side version from the server-side version...)

We've never had problems knowing that the client side is not a java
environment and that things like object output into files is
unrealistic in client code. I don't think that's going to be a large
stumbling block for developers, as custom serialization is, from my
experience, both rare and something that only happens knowingly. You
can't accidentally create a situation where you use custom
serialization without knowing it. If you're already putting the time
in to custom serialize something, you obviously know that something
special is going on and it shouldn't be a huge surprise when that
particular solution, designed for an all-java environment, doesn't
work in an entirely different environment...

As I mentioned in [ http://code.google.com/p/google-web-toolkit/issues/detail?id=21#c21
], I believe the fact that the entire protocol isn't supported should
not be a stumbling block. I am unaware of ANY java contract entirely
supported by GWT. It comes with the territory of working within a far
more limited environment than the standard java environment.

(Or you could just reread Mr. Petersen's post and understand
everything I was trying to say, written in nicer english...)
-Joshua Yanchar