Export to GitHub

google-web-toolkit - issue #21

Lack of java.io.Serializable hurts interoperability


Posted on Sep 19, 2006 by Swift Hippo

GWT Release: 1.1.10

Detailed description: GWT doesn't include a class definition for java.io.Serializable. This is to avoid confusion with GWT's built-in serialization mechanisms. However, not having a definition causes compile errors when trying to use a single set of classes that are both IsSerializable and Serializable. Several users have requested this.

Workaround if you have one: Add an empty Serializable interface to gwt-user.jar as com/google/gwt/emul/java/io/Serializable.java

Links to the relevant discussion group topics (optional): http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/8fe5d325263460e1 http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/30b7a90432d0ced8

Comment #1

Posted on Sep 19, 2006 by Swift Hippo

(No comment was entered for this change.)

Comment #2

Posted on Sep 25, 2006 by Massive Rabbit

(No comment was entered for this change.)

Comment #3

Posted on Sep 26, 2006 by Happy Giraffe

(No comment was entered for this change.)

Comment #4

Posted on Sep 29, 2006 by Quick Kangaroo

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

Comment #5

Posted on Oct 27, 2006 by Massive Rabbit

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

Comment #6

Posted on Nov 4, 2006 by Helpful Monkey

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

Comment #7

Posted on Nov 6, 2006 by Quick Kangaroo

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.

Comment #8

Posted on Nov 18, 2006 by Swift Kangaroo

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.

Comment #9

Posted on Nov 27, 2006 by Helpful Rhino

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.

Comment #10

Posted on Jan 5, 2007 by Grumpy Monkey

+1

Comment #11

Posted on Jan 22, 2007 by Massive Rabbit

(No comment was entered for this change.)

Comment #12

Posted on Feb 14, 2007 by Massive Rabbit

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.

Comment #13

Posted on Feb 16, 2007 by Happy Rhino

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.

Comment #14

Posted on Mar 13, 2007 by Swift Kangaroo

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

Comment #15

Posted on Mar 15, 2007 by Swift Lion

+1 to removing the IsSerializable dependency.

Comment #16

Posted on Mar 15, 2007 by Grumpy Rhino

another one voting for IsSerializable remove :)

Comment #17

Posted on Apr 12, 2007 by Helpful Kangaroo

+1 for removing IsSerializable interface.

Comment #18

Posted on Apr 16, 2007 by Grumpy Ox

+1 for removing IsSerializable interface.

Comment #19

Posted on Apr 19, 2007 by Quick Bird

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.

Comment #20

Posted on Apr 19, 2007 by Quick Ox

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

Comment #21

Posted on Apr 27, 2007 by Swift Panda

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

Comment #22

Posted on May 30, 2007 by Massive Rabbit

Changing to Fixed status with GWT 1.4 RC release

Comment #23

Posted on Apr 28, 2008 by Grumpy Horse

Comment #24

Posted on Feb 9, 2011 by Swift Ox

(No comment was entered for this change.)

Status: Fixed

Labels:
Type-Enhancement Priority-High Category-RPC Milestone-1_4-RC