Lack of java.io.Serializable hurts interoperability about gwt

[dankurka]

Reported by gwt.team.scottb on 2006-09-19 17:40:02

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[dankurka]

Reported by gwt.team.bruce on 2006-09-25 21:14:50

• Labels added: Milestone-1_2_RC

[dankurka]

Reported by gwt.team.ecc on 2006-09-26 18:16:43

[dankurka]

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

Reported by JMGuillemette on 2006-09-29 16:41:17

[dankurka]

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".

Reported by gwt.team.bruce on 2006-10-27 06:52:49

• Labels added: Priority-High
• Labels removed: Priority-Medium, Milestone-1_2_RC

[dankurka]

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

Reported by eclipseguru on 2006-11-04 23:10:47

[dankurka]

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. 

Reported by JMGuillemette on 2006-11-06 18:17:22

[dankurka]

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.

Reported by martin.c.webb on 2006-11-18 10:09:44

[dankurka]

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.

Reported by sandymac on 2006-11-27 04:52:39

[dankurka]

+1

Reported by gass.bofh on 2007-01-05 13:50:30

[dankurka]

Reported by gwt.team.bruce on 2007-01-22 21:45:42

• Labels added: Category-RPC, Milestone-Planned

[dankurka]

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.

Reported by gwt.team.bruce on 2007-02-14 20:58:38

• Labels added: Milestone-1_4_RC
• Labels removed: Milestone-Planned

[dankurka]

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.

Reported by goergen.daniel on 2007-02-16 08:31:40

[dankurka]

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

Reported by martin.c.webb on 2007-03-13 00:30:11

[dankurka]

+1 to removing the IsSerializable dependency.

Reported by treeder on 2007-03-15 02:00:47

[dankurka]

another one voting for IsSerializable remove :)

Reported by marceloemanoel on 2007-03-15 02:23:46

[dankurka]

+1 for removing IsSerializable interface.

Reported by climbingrose on 2007-04-12 06:28:23

[dankurka]

+1 for removing IsSerializable interface.

Reported by andres.a.testi on 2007-04-16 17:18:42

[dankurka]

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.

Reported by gwt.team.mmendez on 2007-04-19 15:41:13

• Status changed: FixedNotReleased

[dankurka]

+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.

Reported by david.nouls on 2007-04-19 18:19:26

[dankurka]

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

Reported by theclassconnection on 2007-04-27 19:54:09

[dankurka]

Changing to Fixed status with GWT 1.4 RC release

Reported by gwt.team.bruce on 2007-05-30 00:17:14

• Status changed: Fixed

[dankurka]

Reported by [email protected] on 2008-04-28 23:32:51

[dankurka]

Reported by [email protected] on 2011-02-09 00:14:01

• Labels added: Milestone-1_4-RC
• Labels removed: Milestone-1_4_RC