GWT Support

[GoogleCodeExporter]

There seems to be a partial implementation of support for use of this
library in client-side GWT code, but it is not yet complete. Any idea when
this will be usable?

Original issue reported on code.google.com by Bitmei...@gmail.com on 14 Jul 2009 at 2:55

[GoogleCodeExporter]

Do you imagine using Munge for making the gwt compatible sources? 

All the JDK serialization can be munged out. If a class is annotated with
@GwtCompatible(serializable = true) does that mean it will work with gwt rpc 
without
custom serializers? If serializable = false then a custom serialized will be 
used?

Original comment by alen_vre...@yahoo.com on 2 Aug 2009 at 12:15

[GoogleCodeExporter]

We are not using Munge at this point.  

We will have a working GWT module as part of our 1.0 release.  Thanks for 
filing this 
issue to track that.

Original comment by kevin...@gmail.com on 12 Aug 2009 at 5:03

• Changed state: Accepted
• Added labels: 1.0

[GoogleCodeExporter]

Any idea when this might be available?  Hate having to hack around this thing.

Original comment by kirills%...@gtempaccount.com on 9 Sep 2009 at 5:06

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:45

• Added labels: Milestone-1.0

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:46

• Removed labels: 1.0

[GoogleCodeExporter]

Does anyone know of a workaround that will at least let you use the parts of 
the 
library that are gwt safe?

Original comment by brianopp on 17 Sep 2009 at 5:50

[GoogleCodeExporter]

I'll get all the CustomFieldSerializers we have so far copied out to the 
project. If 
anyone can volunteer to do the build.xml hackery to build a GWT module... who 
knows, 
it might just work already!

Original comment by kevin...@gmail.com on 16 Oct 2009 at 9:16

[GoogleCodeExporter]

Nice to see progress on gwt support. I've hacked gwt collect a little bit this 
afternoon.

Your EmptySomething Serializers are a bit funny. They don't compile or I am 
missing
something obvious. Basically you are returning EmptyImmutableList but
EmptyImmutableList.INSTANCE is of super type ImmutableList. I changed that. 
Only to
get verious com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException:
Invalid type signature for 
com.google.common.collect.InsertYourFavoriteDataStructureHere.

ImmutableSortedSetFauxverideShim (and ImmutableSortedMapFauxverideShim) should 
be
@GwtCompatible since ImmutableSortedSet is @GwtCompatible and extends it.

How will you support the @Nullable? Etc. There is still some work to do.

Original comment by alen_vre...@yahoo.com on 18 Oct 2009 at 5:41

[GoogleCodeExporter]

The problem with Empty* serializers appears to be a merge hiccup, as the 
INSTANCE
types are declared to be EmptyImmutable* in our internal repository.  I've 
brought
the Subversion repository in line with that.  If you change these types (just 
pull
the latest source from Subversion), rather than the types in the
CustomFieldSerializer classes, does the "Invalid type signature" error go away?

Thanks for the reports.

Original comment by cpov...@google.com on 19 Oct 2009 at 6:48

[GoogleCodeExporter]

While you are at it I think that import com.google.common.base.ReferenceType in
gwtemul com.google.common.collect.Platform should go away.

Somehow having java.io.*Stream and java.util.concurrent emulated in GWT feels a 
bit
deceiving to me. I guess it is necessary evil to get things working. For most 
of the
classes it will not be visible to the user anyway.

I think Invalid type signature comes from the fact that I was munging out 
private
readObject and writeObject methods. Never imagined private methods make a part 
of the
type signature for gwt rpc. Will undo my hacks and report back.

Original comment by alen_vre...@yahoo.com on 19 Oct 2009 at 9:54

[GoogleCodeExporter]

I'm working on this now. Do you have any gwt.xml / build.xml files you've used 
that I could start with?

Original comment by yrfselrahc@gmail.com on 19 Oct 2009 at 9:58

[GoogleCodeExporter]

Very cool to see things moving for GWT support. Just saw the message now. The 
files
are at my home computer. Can send it later this day but I guess you made the 
gwt and
build xml by now. What I did was very simple: copy all @GwtCompatible sources to
arbitrary dir, override with emul, add in the serializers (source and binary), 
some
super sources, gwt.xml and package it in a jar. If you need any help let me 
know.

Original comment by alen_vre...@yahoo.com on 20 Oct 2009 at 8:01

[GoogleCodeExporter]

Here are my build files. I got rid of my strange hacks (now I understand why it 
is
necessary to emulate java.io and stuff). I've done some quick and dirty 
emulation for
java.io and stuff and the serialization works now. Basically all what is 
missing are
the emulated java classes. I'll have time over the weekend to do them properly 
but
maybe you have done them already. ;)

Original comment by alen_vre...@yahoo.com on 20 Oct 2009 at 8:45

Attachments:

• Build_stuff_forgwt.patch

[GoogleCodeExporter]

Of course we've done them already! Just need to work them into this release and 
build.

Thanks for sharing your build patch. That will be very helpful as I try to get 
this all straight.

Original comment by yrfselrahc@gmail.com on 20 Oct 2009 at 8:50

[GoogleCodeExporter]

(By the way, your patch is a bit hard to read as you apparently changed the 
indentation in most of the file. If it's 
easy for you to send a new patch with only your diffs that would be great; 
otherwise I'll keep digging through 
this one.)

Original comment by yrfselrahc@gmail.com on 20 Oct 2009 at 8:54

[GoogleCodeExporter]

Reformat code is habitual by me.

Original comment by alen_vre...@yahoo.com on 20 Oct 2009 at 9:18

Attachments:

• build_xml.patch

[GoogleCodeExporter]

I submitted the code we have so far, as well as a jargwt build rule. I'm still 
playing around with how to the the 
gwt.xml files to work right. This is new to me; if you have any insight into 
how to make this happen, I'd love to 
hear it!

Original comment by yrfselrahc@gmail.com on 21 Oct 2009 at 7:02

[GoogleCodeExporter]

Nice work on the build rule. Very short and simple. I'd prefer for version to 
be the
last part of the jar name but this will do as well.

imho it is a good option for gwt.xml to be placed in
com/google/common/Collect.gwt.xml with source paths being "annotations", "base" 
and
"collect".

Where to put the jre emulated stuff and jsr305 Nullable is another matter. I 
don't
have any strong opinion on how it should be done. What I am concerned about is 
how
this will play with other gwt libraries out there who might also provide jre 
emulated
stuff.

Oh almost forgot to mention. Maybe the gwt specific code would deserve an 
IntelliJ
module? ;)

Original comment by alen_vre...@yahoo.com on 21 Oct 2009 at 9:50

[GoogleCodeExporter]

All right. I've got something that works for some definition of works. Let me 
know what you think.

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 4:12

[GoogleCodeExporter]

I like how you put collect gwt overrides in super dir and the non modified 
sources in
common dir. The only thing I'd do differently is not to have java.Java.gwt.xml 
but
just Jre.gwt.xml or something along those lines.

I am still getting IncompatibleRemoteServiceException. My guess is that the rpc 
is
very pesky about having a 1 to 1 correspondence between the server .class and 
what
gets compiled in javascript. Will take a closer look.

The gwtemul dir can be safely removed. Btw: What do you have in mind for unit 
tests?
I definitely would like to see some tests for gwt serialization.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 1:25

[GoogleCodeExporter]

Great suggestions. I've done them all.

What class are you trying to use in your RPC? Note that not all GwtCompatible 
classes are flagged as 
serializable=true.

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 2:32

[GoogleCodeExporter]

Oh, and I forgot to add: we have tons of internal tests for this. The process 
of getting them into this package 
may not be rapid.

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 2:38

[GoogleCodeExporter]

I've just debugged gwt rpc internals and it happens that no custom field 
serializers
are loaded at all. Oh, it was so obvious! The .class files for serializers are
missing from the gwt jar. I added them and now the serialization works (on the
classes I tested on).

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 3:13

[GoogleCodeExporter]

Here is the changed ant rule. My ant skills are a bit rusty so looking forward 
to
your build rule.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 3:16

Attachments:

• QuickAndDirtyFix.patch

[GoogleCodeExporter]

Help me understand this better: isn't it the case that the class files are 
needed on the server instead of the 
client? The jargwt produces a jar that is only useful on the client. The server 
still needs to depend on the 
standard jar output.

So is it really the case that the compiled serializers really belong in a 
server-side jar, or even just in the "jar" 
target output?

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 3:45

[GoogleCodeExporter]

You are right. The compiled serializers don't fit in the client side jar. But 
they
must be present on the server side. I am in favor of having them in the 
collections
server side jar.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 3:59

[GoogleCodeExporter]

Great progress, guys! I can't wait to use google-collections in my GWT apps ;)

About CustomFieldSerializers, I'm far from being an expert about this subject, 
but I
think we could look at how other libraries did it:
http://code.google.com/p/gwt-math/ , has a "server" jar which only contains the
.class files, and another jar which only contains .java files which seems to be
destined solely to be used by the GWT compiler.

Original comment by nev...@gmail.com on 22 Oct 2009 at 4:06

[GoogleCodeExporter]

Imho having serializers in a separate jar is definitely a good way to go as 
well. I
find it more convenient to have just one server side jar. In any case I think we
can't go wrong either way we do it.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 4:27

[GoogleCodeExporter]

Another thing to consider: when looking for CustomFieldSerializers, the GWT 
compiler
looks both in the package where the class to serialize is located, as well as 
in a
sub-package of com.google.gwt.user.client.rpc.core

For example, ArrayListMultimap's CustomFieldSerializer may be located at
com.google.gwt.user.client.rpc.core.com.google.common.collect.ArrayListMultimap_
CustomFieldSerializer
instead of com.google.common.collect.ArrayListMultimap_CustomFieldSerializer .

In the GWT jars, all the CustomFieldSerializers for jre classes are located in 
such a
sub-package. Some other projects did the same (like gwt-math).

I think we should consider doing this, since these serializers are more of an
"implementation detail", and putting them in the "com.google.common.collect"
namespace would "clutter" this package with many classes of no interest for 
standard
development.

Original comment by nev...@gmail.com on 22 Oct 2009 at 4:43

[GoogleCodeExporter]

It makes sense. Like for JavaDocs I don't want to see _CustomFieldSerializer in 
the
com.google.common.collect package at all. I'd go for 
com.google.gwt.user.client.rpc.core.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 5:22

[GoogleCodeExporter]

I just submitted a change to build the serializers into the primary jar. I just 
left them in their normal place since 
that's less work for me. And they don't pollute the source code, so this is 
really just about jar prettyness, and I 
see no reason to optimize for that. :-)

Let me know how this works.

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 5:27

[GoogleCodeExporter]

It works fine. Nice work! I'd remove google-collect-${version}.jar from 
serializers
javac build rule and rename super in gwt/com/google/common/ to emul or override.

I tried out to serialize a few collect classes - it works fine! :) Sweet.

I'd like to point out that for e.g. HashBiMap that isn't serializable = true 
there is
no exception if you serialize it. The client just receives a HashBiMap with 0
elements. I find that quite unintuitive. I'd expect to see an exception like
NotIntendedForSerialization than just empty collection.

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 7:09

[GoogleCodeExporter]

Ad rpc package: My comment about javadoc was totally off. Don't know what I was
thinking. I looked at the gwt rpc source a bit closer. The
"com.google.gwt.user.client.rpc.core" is known as JRE_SERIALIZER_PACKAGE. It 
makes
perfect sense to put java BigInteger serializer in there. But collect is not 
part of
jre. I tested putting serializers in jre serializer package to see if it made 
any
difference to IntelliJ. It didn't. Makes sense. ;-)

Original comment by alen_vre...@yahoo.com on 22 Oct 2009 at 7:52

[GoogleCodeExporter]

The serializers go into the same jar, so I think it's fine for them to be in 
the same rule.

I also personally prefer emul over super, but the fact of the matter is that 
GWT themselves talk about it as 
super-source, so I'll leave it as super.

As for your HashBiMap issue, that is all about GWT. Don't know what else to say 
there.

By the way, thanks for the patches you sent to help me figure this out. They 
were instructive, and saved me 
lots of time!

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 7:52

[GoogleCodeExporter]

Original comment by yrfselrahc@gmail.com on 22 Oct 2009 at 7:52

• Changed state: Fixed