(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

This is extremely important for being able to cleanly integrate gwt framework with
other frameworks like spring or hibernate

We talked about this one a lot and (1) it definitely needs to be addressed and (2)
the exact solution is controversial enough that we shouldn't hold up 1.2 RC until we
figure out the right answer.

I'm taking off of 1.2 RC but I'm increasing the priority to "High".

Do you think it's possible to deprecate IsSerializable and use java.io.Serializable
instead?

From a standards prospective that would make alot more sense.
Deprecate IsSerializable and implement Serializable.

Most people who are fighting for this are doing so cause of integration requirements.
I like to use hibernate for example. My POJO's out of the database are by nature
Serializable. I cant send them to the display layer however because of the
"serialiable" issue.. Instead i have to now translate them to antoher pojo that
doesnt implement serializable (but IsSerializable) to send it up...  since both
methods are empty implementations.. why not merge them together. 

Out of the two possible options identified so far:

1. Add an empty Serializable interface to gwt-user.jar
2. Deprecate IsSerializable and use java.io.Serializable instead

I would strongly request option 2 - currently having to write wrappers around our
services to convert objects which will slow take up within our larger internal and
offshore developer community for the telco I work for.

We can't afford to pollute are service and domain tier DTOs with IsSerializable.  Any
work required to provide a wrapper is overhead in terms of development and test
effort.  We want to be in the situation that we mandate to our development community:
code to interfaces, and everything is implemented as POJO.  We then are in a position
where the POJO can be consumed in struts/tiles apps, converted to XML on the fly for
third party mashups, and consumed by GWT.

The later can't currently happen whilst we need to implement IsSerializable.

While we wait for GWT to include java.io.Serializable if you add GWTx to your project
you can use classes that implement java.io.Serializable in your client code. See:
http://code.google.com/p/gwtx/ for details.

+1

(No comment was entered for this change.)

This is a major inconvenience for integration cases. We have essentially agreed that
we want to remove IsSerializable in a future release, very likely in the release
after 1.4. However, since we haven't finalized the semantics for that change (i.e. do
we honor Serializable? do we serialize anything at all?), we're not ready to actually
make Serializable mean anything. 

We should strongly consider at least including java.io.Serializable simply for the
sake of not preventing integration cases. IOW, resolving this issue is explicitly
*not* removing IsSerializable nor is it making Serializable actually have any effect.

Yes please include that in the next release! I am tired of using copy constructors :O)
Serializable doesnt have to have an effect on client side but if you want to
serialize a bean that implements IsSerializable this is really a pain.

Bruce,

I'd be happy to allow Serializable not to mean anything.  However, "*not* removing
IsSerializable" is not the step in the right direction that I was looking for.  By
leaving IsSerializable as a necessary requirement for implementing asynch services is
tainting, otherwise technology/framework agnostic code, with a GWTism.

*IF* we could take a bulk standard POJO and _somehow_ add the IsSerializable marker
interface to the standard POJO at either Java 2 JavaScript code generation time or
run time, *without* affecting the source of the original POJO then I'd be immensely
happy!

I'm assuming (as I've not looked at the source code) that you are using
IsSeriablizable as a marker to the Java2JavaScript code generatorto know what data
needs to be supported across the wire?  If thats the case, and as you are using a
Java2JavaScript code generator cannot you implement a different marking schema
external to the source code.  I know it would get tricky with nested POJOs, i.e.
which of the nested POJOs are serialiable or not...

I don't know or understand the technical details of GWT - but supporting Serializable
as an internal means to mark the code is the obviously perfect mechanism! ;)

Happy to dialogue further if it would help...

What does IsSerializable do that it is so fundamental to the solution?

Regards
Martin

+1 to removing the IsSerializable dependency.

another one voting for IsSerializable remove :)

+1 for removing IsSerializable interface.

+1 for removing IsSerializable interface.

Added java.io.Serializable.  Removing IsSerializable will be addressed in the
subsequent release.  I created a new issue
http://code.google.com/p/google-web-toolkit/issues/detail?id=947 to track that
specifically.

+1 for removing IsSerializable interface.
Whatever the technical details are, I can not sell a GUI/middleware if we must polute
the database tier. So I guess we have to wait for after GWT1.4. In a strict
environment we must follow the rules to get past the review process.

From what I've read in other threads, there is resistance to making Serializable
actually mean anything because the entire contract entailed by serializable in a java
environment could not be honored in GWT.  That's a rather weak argument though, as
almost EVERY class in the emulated java classes are limited beyond their java
contracts.  There are some Collections methods that would be really nice to have in
my application (retainAll and the like...) that are not supported.  They're part of
the collections contract, but failing to fully enforce THAT contract didn't prevent
you from implementing ArrayList and others.  More importantly, it didn't stop the
limited versions of these classes from being useful.

Even a relatively limited version of Serializable would be useful in a very similar
way.  Yes, you would have to ensure that you follow the supported parts of the
contract and do not rely on unsupported portions; but that is in no way different
from what you have to do in any other instance working with GWT.

-Joshua Yanchar

Changing to Fixed status with GWT 1.4 RC release