This change represents a significant problem for us. Currently in our
application we have gwt-servlet.jar in our APP-INF/lib directory of
our EAR file. This directory is recognized by Weblogic 8.1 as being on
the classpath for all EJB and WAR modules in the EAR. Our business
logic for our application is a mix of EJB code in the form of
Stateless Session Beans with calls to the backend DB implemented using
Hibernate. Our RPC servlet layer just delegates the calls to the EJB
tier. This gives us transaction and security support for our business
logic.

In our application we have a set of value objects that implement
IsSerializable that are shared by our GWT client codebase and by the
EJB tier code. For our EJB tier to compile and go through all of the
packaging process we are required to have gwt-servlet.jar on the
classpath because the EJB tier code depends on the value objects. We
cannot move the gwt-servlet.jar file to WEB-INF/lib to get it on the
web application classloader. Trying to place the JAR file in both
locations does not work either. In general we have been able to place
JAR files at the APP-INF/lib directory and have it work. Is your
custom classloader taking into account that it might be part of a
hierarchy of classloaders?

This represents a critical issue for us, since we have a significant
amount of code that is currently running in production on GWT 1.2 and
have no mechanism to migrate to GWT 1.4 

I believe that comment #1 was intended for  issue 1138 .

(No comment was entered for this change.)

Updated the synopsis to reflect he real scope of the problem.

None of our JRE classes implement java.io.Serializable.  This can cause differences
between the server and client with regards to the set of types which are
serializable.  It can also cause CastClassExceptions on the client.

We need to go over our JRE classes and add java.io.Serializable where appropriate. 
It may also be necessary to add custom field serializers to make sure that the client
and server have the same serialized view of a type.

(No comment was entered for this change.)

I took a rough cut a doing this and I ran into several problems.  

1) Our class library has several classes which extend ArrayList, HashMap, etc.  These
subclasses are not default instantiable and result in additional errors/warnings. 
There is not a good way to suppress these today; we'd need to figure out an approach.

2) There are several classes which do implement Serializable in the real JRE but
could cause problems for us.  For example, Class, EventObject, StackTraceElement,
StringBuffer, and Throwable all implement.  Adding Serializable to these will have
implications that we need to deal with.

3) The 1.4 RPC actually forces all subtypes of auto serializable types to be
themselves serializable.  This is actually a regression in RPC since 1.3.3 did not
have this restriction and it is actually a bug with the 1.4 system.  However, I think
that it is what you want for the classes that you define to be used over RPC.  I'm
not sure that we should fix this since it removes failures at the cost of being more
strict.  Adding Serializable to our JRE could magnify this problem.

(No comment was entered for this change.)

Another way this issue manifests itself, is when using a common pattern for
business-logic exceptions:

public class MyException extends Exception implements Serializable {

[...]

	public MyException(String message) {
		super(message);
	}

[...]

}

If I set a message to accompany the exception via:
throw new MyException("blah")
when the exception reaches the client, the "blah" message is lost, presumably due to
Throwable not being Serializable.

A workaround is to store a message with MyException and override getMessage() to
return it.

We should really resolve this for 1.5

This caused me quite some headache as well since I was trying to implement the pattern described here in 
comment #8.  I would expect that the documentation at  http://code.google.com/webtoolkit/documentation/
com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.HandlingExceptions.html  should mention this.  
Since every AsyncCallback is handling a descendant of Throwable for failure, it makes sense to some of us Java 
programmers to use the Exception/Throwable's capacity to hold a message (and 'cause' as well...).

(No comment was entered for this change.)

How about [1356]? It is marked as duplicate of this, but it has nothing to do with
rpc, it is totally client-side:
Serializable a = "Hello";
Object b = a;
String c = (String) b; //Works
String d = (String) a; //Don't work - compile error.

Committed as r1578.

This commit did not add Serializable to Throwable.  The reason was that it causes all
exception types available on the client to end up in the final code whether they are
used or not.  Perhaps the cause field could be transient; I'm leaving this issue open
until we get some feedback on the upcoming milestone.

EnumMap, EnumSet, LinkedHashMap and LinkedHashSet were not updated with Serializable
because their implementation is not yet complete.  

TreeMap, TreeSet, and PriorityQueue were not updated because they can accept a
comparator via the constructor.  This comparator could use JSNI which would result in
potentially hard to debug serialization errors.  FWIW, Java Serialization can suffer
from the same problem. 

Reply to Comment #12.

Serializable was added to java.lang.String.  Do you still have the compile time error
using r1578?

Guys, the current behaviour for Throwable is highly unintuitive. Is there any chance
you could update the RPC wiki documentation to mention this caveat - at least until
this ticket is resolved?

I'd love to see a resolution to this issue. It would be great if the default JRE
exceptions were available to the RPC mechanism, so that we don't have to create
exception wrappers for the basic JRE RuntimeExceptions (or their messages or causes).

Miguel, should this issue be FixedNotReleased?  I see that a commit was done.

I left it open to remind me to get a sanity check on how we should handle Throwable
now that we added Serializable to our JRE.  The options seem to be:

1) Update the documentation to clarify that user defined exceptions should extend
SerializableException, whose only purpose is to provide a message field that can be
serialized.  This still leaves us with the unintuitive handling of the message field.

2) Add Serializable to Throwable.  This could cause all Throwables to be picked up
via its cause field.  We could make the cause field transient in our JRE and then use
a CustomFieldSerializer to ensure that these are not serialized from the server to
the client.  We may also want to mark the stacktrace field as transient.

My vote would be for option 2) above. 

The justification being that this is the solution most consistent with typical Java
development. Throwable is already Serializable so it would be counter-intuitive to
have to extend a GWT specific 'SerializableException'. Furthermore, having to extend
a GWT specific exception could lead to 'bleed' of application layer dependencies into
other layers of an application (domain, etc).

Finally, the problem of non-Serializable cause fields (mentioned in 2 above) feels
similar to the problem of Throwable subclasses with non-Serializable, non-transient
fields in regular Java. Could I suggest a couple of alternative solutions:
1. Don't mark the cause field as transient - detect the problem during execution and
throw an appropriate exception.
2. Convert Throwables that GWT doesn't understand to a standard Throwable with a
corresponding stack trace and serialize this instead.

Added Serializable to Throwable; the GWTC thread has subject: Code Review:
throwable-implements-serializable-r1914.patch.

WRT comment #19, we do throw an appropriate exception if you try to serialize
something that the client can't handle.  The reason for marking the cause field as
transient is to prevent the client side code bloat because it would need to be able
to serialize every possible subtype of Throwable that the client side code knows
about.  RPC2 maybe able to do something smarter about this.

I have mixed feelings about the conversion of Throwables; it seems out-of-scope for now.

Added Serializable to Throwable.  Committed as r2047.

I got into exactly the same problem with non IsSerializable exceptions. I tried to
use the fix with the 1.4.62 release, but I got into the same problems. So Throwable
is still not Serializable? Will it only come with 1.5?

Please see comment #21.

There are situations where it would be extremely useful to have the stack trace
serialized, so that you don't have to go hunting through server logs to identify the
troublesome code path (particularly when your app is in a testing environment).

Any chance on an option to make it serialized along with the detail message?

Could you file a new issue for this?

1_5_RC has been released.