Public Service Announcement: Google Collections Library 0.5 (ALPHA)

[Kevin Bourrillion]

Hello esteemed guice-users,

I'm sorry that I have been largely inactive on guice development and
discussions these past few months -- but at least now I finally get to
tell you what I've been working on! (I do intend to come back.)

If you'll forgive the spam:

I've just posted the first public alpha of what we're calling "the
Google Collections Library." (Continuing our long tradition of
creative product naming.) This is a package chock full of collections
and related utilities that fill in what we most felt was missing in
the JDK. We built it to support our legions of Java developers and
projects internally, but now we're opening it up to the world.

The project page is http://google-collections.googlecode.com, and I'll
lift a quick overview from that page right here:

----- snip -----

The major new types are:

* BiMap. A Map that guarantees unique values, and supports an inverse view.
* Multiset. A Collection that may contain duplicate values like a
List, yet has order-independent equality like a Set. Often used to
represent a histogram.
* Multimap. Similar to Map, but may contain duplicate keys. Has
subtypes SetMultimap and ListMultimap providing more specific
behavior.

There are also more than a dozen collection implementations, mostly of
the interfaces above, but not all. ReferenceMap, for example, is a
ConcurrentMap implementation which easily handles any combination of
strong, soft or weak keys with strong, soft or weak values.
[ReferenceMap is Bob's creation and also happens to be copied into the
Guice sources, but please pretend you didn't know that!]

Static utility classes include:

* Comparators. Natural order, compound, null-friendly, ad-hoc . . .
* Iterators and Iterables. Element-based equality, cycle, concat,
partition, filter with predicate, transform with function . . .
* Lists, Sets and Maps. A plethora of convenient factory methods
and much more.
* PrimitiveArrays: "boxing"/"unboxing" of primitive arrays

And there's more:

* Forwarding collections
* Constrained collections
* Implementation helpers like AbstractIterator

----- snip -----

There's a shortage of concurrent collections beyond ReferenceMap, but
we do have a ConcurrentMultiset that should be ready pretty soon.

I really hope you will find this library useful. You're all very
welcome to check out what we have here so far, and please send us your
feedback!

K

--
Kevin Bourrillion @ Google
google-collections.googlecode.com
google-guice.googlecode.com

[Robbie Vanbrabant]

I found it the other day through Jesse's blog: http://publicobject.com/

He has a series of interesting blog posts about Google Collections.

Great stuff, guys!

 

Robbie
 

[Gregory Kick]

This looks like a great set of tools. The one thing that I wanted to
bring up is that we now have Provider<T> from Guice and Supplier<T>
from google-collections that do/mean the exact same thing. Does it
make sense to deprecate Provider in favor of the "more widely scoped"
Supplier?

--
Gregory Kick
http://kickstyle.net/

[Brian McCallister]

On Sep 13, 2007, at 8:32 AM, Gregory Kick wrote:

>
> This looks like a great set of tools. The one thing that I wanted to
> bring up is that we now have Provider<T> from Guice and Supplier<T>
> from google-collections that do/mean the exact same thing. Does it
> make sense to deprecate Provider in favor of the "more widely scoped"
> Supplier?

Only if google-collections is already guice dependency. As the
methods match having one class implement both is easy and allows for
not having the additional dependency.

-Brian

[Robbie Vanbrabant]

It could make sense to use it. As the collections faq says, Guice already uses ReferenceMap, and could make good use of all the factory methods. They got my vote. And what's a dependency when you've got Jarjar :-)

 

Robbie
 

[Bob Lee]

On 9/13/07, Robbie Vanbrabant <robbie.v...@gmail.com> wrote:

It could make sense to use it. As the collections faq says, Guice already uses ReferenceMap, and could make good use of all the factory methods. They got my vote. And what's a dependency when you've got Jarjar :-)

Well, ReferenceMap is purely an internal dependency, so jarjar would work, but using Supplier in the API would make all of Google Collections part of our public API, and we wouldn't be able to use jarjar.

It's probably not worth adding our first external dependency (outside of AOP Alliance) just for a single method interface. Now, if we need to use Multimap, etc., in our API, that's a different story.

Bob

[Robbie Vanbrabant]

Why wouldn't we be able to use jarjar for a public API? Supplier<T> has no dependencies on the rest of Collections. Anyway, I'm thinking about this as code we don't need to maintain. If we can use their code, we should, and this doesn't have to mean we have to add an explicit dependency. A lot of it will be for internal use, like the factory methods that do type inference. Using Supplier<T> is less of an issue for me as we've settled on Provider. That's perhaps something we could consider for a 2.0.

 

Robbie
 

[Kevin Bourrillion]

Yeah, this drives me nuts :-) in fact I think we're going to try to
retract Supplier from the library; it's only used in like one place.

Thanks so much for the kind words!

[Bob Lee]

Yeah, we'll definitely use it internally (w/ jarjar), and maybe even externally if it makes sense.

Bob

[Brian Pontarelli]

Kevin,

Looks suite dude! I wrote some similar Collection stuff that you guys
might find (I know I do) useful. I have a few extra conveniences method
for building some common Maps and also a Pair object. Also, I have a
graph laying around in Savant, that I plan on moving over to Java.net
Commons at some point, which might be useful for you collections.

Here's some pointers to the JavaDoc for those:

http://inversoft.org/javadoc/java-net-commons/1.3/net/java/util/CollectionTools.html
http://inversoft.org/javadoc/java-net-commons/1.3/net/java/util/package-summary.html

http://inversoft.org/javadoc/savant/2.0/net/java/savant/dep/graph/Graph.html
http://inversoft.org/javadoc/savant/2.0/net/java/savant/dep/graph/package-summary.html

-bp

> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "google-guice" group.
> To post to this group, send email to google...@googlegroups.com
> To unsubscribe from this group, send email to google-guice...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/google-guice?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
>

[Sam Berlin]

So long as we're sharing, if you're interested in including a Patricia
Trie (and, well, who isn't!)...

JavaDoc at: http://www.limewire.org/nightly/modules/collection/api/org/limewire/collection/PatriciaTrie.html
Code at: https://www.limewire.org/fisheye/browse/~raw,r=MAIN/limecvs/components/collection/src/main/java/org/limewire/collection/PatriciaTrie.java

It's been contributed to the Jakarta Collections library also, but
folks there seem to be very backed up.

Another somewhat useful tool is 'RandomSequence', which lets you
generate a uniquely random sequence from 0 to N, never repeating the
same number twice.

JavaDoc: http://www.limewire.org/nightly/modules/collection/api/org/limewire/collection/RandomSequence.html
Code:
https://www.limewire.org/fisheye/browse/~raw,r=MAIN/limecvs/components/collection/src/main/java/org/limewire/collection/RandomSequence.java

Anyway, I'm sure there's a better place for posting all this... so
direct me as needed. :)

Sam

[Endre Stølsvik]

Robbie Vanbrabant wrote:
> I found it the other day through Jesse's blog: http://publicobject.com/
> He has a series of interesting blog posts about Google Collections.
> Great stuff, guys!

Wouldn't it be an extremely good idea to shove those blog posts into the
javadocs?! For several classes, I found the javadocs somewhat lacking in
the "nice, but what to use for?" department, but those blog posts really
cleared everything up. So - obvious solution: cut and paste the blog
posts into the javadocs?

Kind regards,
Endre.

[JR Boyens]

How are these licensed? The Limewire project as a whole seems to be
GPL'd, are these implementations under the same license?
--
JR

[Sam Berlin]

The current licenses are GPL, however we can relicense and donate as
necessary. We offered an Apache-licensed PatriciaTrie to the
commons-collection project (it's just still sitting in the JIRA).
While writing it, we couldn't find *any* complete (or even usable)
Java implementations to use as a reference point (searching on Google,
etc..), so it'd be pretty awesome to push the PatriciaTrie out there.

Sam

[Dhanji R. Prasanna]

I agree. There is a woeful lack of Tree and Heap data structures in the JCF (does Joshua Bloch read this list? ;)

Great job on the Trie, btw. Can you release the code as Apache 2.0 for individuals to use? I would love to use this in my pet projects or even at work.

Dhanji.

> >>> The project page is http://google-collections.googlecode.com , and

[Sam Berlin]

I've created an issue in the Google Collections group at:
http://code.google.com/p/google-collections/issues/detail?id=5 with
the necessary files for the trie. You can consider them licensed
under ASF 2.0 (which we already licensed them under, for inclusion
with commons-collection). Use away!

Sam

[Dhanji R. Prasanna]

Thanks!