Why is GWT serialization so complicated?

[Martin]

Hello

GWT constraint us to use as specific types ass possible. That
constraint us to pass Object over RPC.My application is very dynamic
and therefore I often need to pass Map<String, Object> as argument or
return value. Even if I get warning when compiling such code, it will
not work if I put there instance of some MyObject unless this type is
in the same model object as the Map.

Why couldn't be de/serialization trivial as in following example?

public class Deserializer {
private Map<String, Deserializer> typeToDeserializerMap = ...;

public Object deserialize() {
String type = reader.readString();
Deserializer deserializer = typeToDeserializerMap.get(type);
if (deserializer == null) {
throw new UnsupportedTypeException(type);
}
return deferializer.deserialize(reader);
}

}


now MyObject has 2 arguments: String and Object

public class MyObjectDeserializer extends Deserializer {
public MyObject deserialize(SerializationStreamReader reader) {
MyObject myObject = new MyObject();
myObject.setMyString((String) deserialize(reader));
myObject.setMyObject(deserialize(reader));
}
}


Deserializers for custom object would be generated while compilation.
Isn't that possible with deferred binding already? I can't use
CustomFieldSerializers for all model objects I have because there must
be some automatic way. Any hint? RPC serialization is frustrating me
every day and form mne it is a big unfortunate in such great GWT.

Thanks in advance!

[gregor]

Hi Martin,

Check out Scott Blum's solution here (I've tried it and it works):

http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#

You have to declare a template field in a DTO wrapper for each type
you want to return in a generic collection to get round the RPC
serialization restrictions but for that small cost I think you retain
efficiency and security. This post from Summit Chandel explains the
reasons for the restrictions.

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3bb11f01a5004cdc#


regards
grergor

[Martin]

Hello

Thanks for reply, Gregor.

> http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/25d151960b48b5c4#

I don't like this solution much. It is not very clean and it is hard
to map DTO object to my persistence layer (in my case JCR via our
proprietary OCM). Moreover I can't redesing all our model objects now.

> http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3bb11f01a5004cdc#

please read my reply there

--
Martin

[gregor]

Hi Martin,

>
> I don't like this solution much. It is not very clean and it is hard
> to map DTO object to my persistence layer (in my case JCR via our
> proprietary OCM). Moreover I can't redesing all our model objects now.
>

I don't think Scott is suggesting anything like that - basically
nobody seemed to know how to get a collection of arbitrary different
objects stacked in a collection across RPC and Scott quickly came up
with the two key elements that enable it in the example DTO class and
custom serilizer:

1) You declare "expose" fields for each type you may need to transport
2) you write the simple custom serializer as shown

I don't think there is any suggestion that you change your domain
model objects or persistence mechanism as a result of this (perhaps
Scott's DTO class would be better named something like
GenericRpcPayloadObjectWrapper). Your actual domain objects are put
inside their wrapper objects in the value property, so you can dig
them out client side using object getValue() and check for what types
they actually are.

I think it would be straight forward to construct a more sophisticated
version of this built around your preferred collection (ArrayList, Map
whatever) that simply exposed methods for loading objects into it
server side and returned an iterator for reeling them into your app
client side such that the mechanics would be almost invisible to your
main application code, or at least almost identical to what you would
do if you were able to use a standard Map or List class for this
purpose.

regards
gregor

On Aug 19, 2:47 pm, Martin <m.zd...@gmail.com> wrote:
> Hello
>
> Thanks for reply, Gregor.
>

> >http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse...

>
> I don't like this solution much. It is not very clean and it is hard
> to map DTO object to my persistence layer (in my case JCR via our
> proprietary OCM). Moreover I can't redesing all our model objects now.
>

> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...

[Martin]

Hi Gregor

For me it seems that I _must_ change my model object. If I currently
have

public class MyObject {
private List<Object> objList;
private Object obj;

// standard getters and setters
}

i must rewrite it to

public class MyObject {
private List<DTO> objList;
private DTO obj;

public List<Object> getList() {
((DTOList) objList).getList();
}

public void setList(List<Object> objList) {
this.objList = new DTOList(objList);
}

public Object getObject() {
return obj.getObject();
}

public void setObject(Object obj) {
this.obj = new DTO(obj);
}
}

Am I right?

What I don't like here in addition is that serialized DTO object will
look like many null values and one non-null value. This is not very
bandwidth friendly.

[dolc...@gmail.com]

You could easily write a custom serializer (look for examples in the
GWT source: ArrayList_CustomSerializer) that could output a char (I
for int, L for long, etc) and then the object. When reading in it can
read a char, notice it is an 'I' for int, and then read an int from
the stream. From there you can cast it into a custom type (DTO) that
will only reside on the client side, there for the rest of your pure
java code can remain the same.

[Martin]

I have already written some custom serializers. But this is tedious to
do it for every type and it would be ugly to introduce new custom List
type on client/server.

[Ping]

I'm using maps like <String, Serializable> and I don't need to write
any custom serializer.

[Mehdi Rabah]

same here.. I'm using ArrayList, HashMap, HashSet in RPC async calls and I don't have any kind of problems

can you describe your exact problem ?

[walden]

Back in the day, there used to be a guy here called "Renier", who used
to harp on the fact that GWT is not Java. The mindset of "fully
generic solutions" simply does not play here. We are building
networked applications savagely optimized for the runtime experience.
We sling extra boring code sometimes in order to achieve that higher
goal, and that's just fine. GWT will never be Java, and "fully
generic solutions" are for sophmores anyway.

Just my two cents!

Walden

> > > type on client/server.- Hide quoted text -
>
> - Show quoted text -

[Ian Petersen]

On Wed, Aug 20, 2008 at 10:05 AM, walden <wmat...@aladdincapital.com> wrote:
> Just my two cents!

Make that four cents--I share the same opinion. I also miss Reinier.

Ian

[Reinier Zwitserloot]

Too much traffic and not enough time to read everything, I'm afraid.
But, I do hang out on freenode's ##GWT if you have questions!

I'll try not to disappoint:

Guys, GWT simply isn't java! :P

The basic idea behind GWT's serialization system, at least as far as
the client is concerned, is that its a new 'source of object types'.
This is problematic, because GWT is, quite unlike java, a 'closed
world' compilation scenario: There is no reflection, no class loader,
and no 'classpath'. The code that was there when your project was
compiled is all there is. GWT will start at the entry point(s) and do
some static analysis to figure out which types are even needed, and
simply doesn't include the rest in the resulting JS file. This is
good, because that JS file needs to be as small as it can be.

Serialization is an unfortunate chink in the armour here: It's another
way for objects to enter the system, and especially with 'Object', GWT
has absolutely no idea what that might be. Effectively, without more
specific stuff, it would have to assume every single source file
inherited for this compile job is theoretically 'reachable', and thus
compile all of it. This is kinda sucky, especially if you are e.g.
including big projects like gwt-ext, where, often, three quarters or
more is never actually used and thus not included.

I'm not 100% sure how GWT's serialization works (to be honest, I
always used JSON), but as long as you tell GWT which exact object
types will be coming in, it should still work.

It looks like there IS room for improvement, though. If you go through
the extra hoop of manually enumerating the types that any given
Synchronization bridge can use (only inbound is important, from client
to server doesn't matter because the server has all the code included,
obviously), then you could make it a fully generic solution, that
simply breaks if you try to send an object of a type you didn't
enumerate.

... I think. Again, I don't actually use GWT's serialization
mechanisms, so take this with a grain of salt.

On Aug 20, 4:25 pm, "Ian Petersen" <ispet...@gmail.com> wrote:

[Martin]

Hello

> It looks like there IS room for improvement, though. If you go through
> the extra hoop of manually enumerating the types that any given
> Synchronization bridge can use (only inbound is important, from client
> to server doesn't matter because the server has all the code included,
> obviously), then you could make it a fully generic solution, that
> simply breaks if you try to send an object of a type you didn't
> enumerate.

My words! Why doesn't GWT allow to use Object for RPC and to only
allow pass types, that are already used directly for RPC. For these
will GWT generate serializers. In addition there should be one place
to explicitly tell what other types do I want to pass in RPC as
Object, for which would GWT normally generate no serializer.
Module.gwt.xml would be a good place to specify those explicit types.
Wouldn't be that great? :-)

I have mentioned that later also in
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3bb11f01a5004cdc