Google Collections 1.0 will not support GWT

[Kevin Bourrillion]

If you don't play to use Google Collections 1.0 in Google Web Toolkit
applications, you can skip this message.

For a year we have worked very hard to make as much of our code as
possible function correctly in GWT, and to test that it does. We knew
that for 1.0, performance in GWT would certainly not be stellar, but
suboptimal support would be better than no support at all.

However, more and more teams are finding not just the performance, but
more importantly the effect on the download size of the javascript
bundle to the browser, to be intolerable. Internally to Google, if
you seek out guidelines for how to make your GWT applications download
faster, one of the first things you'll find is "don't use the Google
Collections Library."

Ouch!

As a result, we have work under way that should cut our download size
in half, and we hope we can slim down even further than that. But
this issue, when put together with GWT serialization issues and bugs
that occur only on GWT, have resulted in a situation where GWT support
is by far the major factor holding up our 1.0 release.

We need to drop GWT support from the 1.0 release. However, we'd leave
all the necessary files in subversion so that you to make your own
build and use it at your own risk.

I'm sending this to collect any concerns or other thoughts you may
have! Thanks.

--
Kevin Bourrillion @ Google
internal: http://go/javalibraries
external: guava-libraries.googlecode.com

[fishtoprecords]

On Nov 5, 6:29 pm, Kevin Bourrillion <kev...@google.com> wrote:
> If you don't play to use Google Collections 1.0 in Google Web Toolkit
> applications, you can skip this message.

> I'm sending this to collect any concerns or other thoughts you may
> have!  Thanks.

I am not yet using GC with GWT, but I plan to. And right now, I'm
using GoogleCollections everywhere.

Since no one else has chimed in with a comment, I will offer this:

Sure, its not great news that its more work than you thought to
support GWT properly. But sometimes this happens. Just document it,
and give a hint of a roadmap for when it will be supported, say 1.5 or
perhaps as soon as 1.1. We can plan around it.

[Kevin Bourrillion]

Thanks for that.  What will happen is that all this code is going to be merged into the Guava project, a Guava release will happen, again sans GWT support, and hopefully early in '10, some subset of Guava (closely resembling the subset of this project) will become a supported GWT module.

[Vladimír Oraný]

in case such a core library as Guava or GC wouldn't be better to
create native javascript implementation for GWT instead? maybe
starting with gwt compiled one and trying to optimize it. I think
there is a lot of great javascript programmers in Google which could
do this.


2009/11/6 Kevin Bourrillion <kev...@google.com>:

[Kevin Bourrillion]

It's not quite as bad as that, I don't think, but we do have to create
separate Java emulations of our "real" classes which can be
tailor-made to work great in GWT. For example, internally
ImmutableList will be able to map directly onto native Javascript
arrays. Or something like that. Point is, from the user's
perspective, you can just code to the ImmutableList API, and you'll be
fine.




2009/11/6 Vladimír Oraný <vladimi...@gmail.com>:

[Kevin Bourrillion]

Moreover, we've found that many of the issues that are causing us trouble are GWT bugs that will be fixed in the forthcoming GWT 2.0 release.  So, we are tentatively expecting that our initial rollout of official GWT support will require GWT 2.0.  (Our release will certainly be after theirs.)  If there are any serious concerns about this, we can't promise we'll be able to accommodate them, but we would like to hear and ponder them.  Thanks.

[Alen Vrecko]

It will be ready when it will be ready. That is the best approach for
quality. ;)

There is one thing I've been wondering since the start. Why do you
want to have 100% mapping between SE and GWT version?

Having ConcurrentMap and ObjectStreams emulated feels a bit odd.
Certainly I don't want to write

ConcurrentMap map = MapMaker.makeMap();

in GWT. So why support this?

I think there can be just a little asymmetry between SE and GWT.

Cheers
Alen

On Nov 30, 8:27 pm, Kevin Bourrillion <kev...@google.com> wrote:
> Moreover, we've found that many of the issues that are causing us trouble
> are GWT bugs that will be fixed in the forthcoming GWT 2.0 release.  So, we
> are tentatively expecting that our initial rollout of official GWT support
> will require GWT 2.0.  (Our release will certainly be after theirs.)  If

> there are any serious concerns about this, we can't *promise* we'll be able

[Hayward Chan]

In the current state of things, these emulated stubs are necessary for
the code to compile in GWT. In the long term, once the collection
classes themselves are emulated and optimized for GWT, these stubs
won't be necessary.

Hayward

> --
> Google Collections Library - users list
> http://groups.google.com/group/google-collections-dev?hl=en
>
> To unsubscribe, send email to:
> google-collections...@googlegroups.com