Im a strong proponent of using the g-c library and a recent convert. Unfortunately 'typing' is what programmers spend a significant proportion of their time doing and so anything which lets me type less and think more makes me happy. Using g-c significantly speeds the use of Autocomplete in my IDE which in many ways highlights an issue with the package structure of collections in Java in general. I can type "Lists." trigger autocomplete and be presented with the majority of List related functionality I would ever want and progressively refine from there. For neophytes this should actually be easier than typing "new ArrayList" or "new LinkedList" as they should know they want a List first and the implementation later.
The Java collections package is OK but is far from perfect and the g-c is an improvement IMHO. E.g. com.google.common.collections.ImmutableList.of(E...) vs. java.util.Collections.unmodifiableList(java.util.Arrays.asList(E...)) less verbose and avoids the gotcha of modifications to the underlying view in unmodifiableList which I have seen bite people. Multimaps are really useful, we want to use them for HttpRequest at some point for query parameters. As with all libraries they're only as useful as you make them, I think this one is almost always better than the alternative from a verbosity perspective and so I'd rather do big-bang and use it all the time where possible for consistencies sake. On Sun, Jan 11, 2009 at 11:46 AM, Henning Schmiedehausen < [email protected]> wrote: > On Fri, Jan 9, 2009 at 18:09, Paul Lindner <[email protected]> wrote: > > It's not a need, it's a want. As in: > > [... personal snipe removed ...] > > > In the same way I (and others) want to use google-collections because it > > makes Java programming more productive. It eliminates boilerplate code > and > > provides an impressive amount of functionality that improves on the base > > Java Collections Framework. > > > > What exactly do you want Henning? Do you want to vote on whether we use > g-c > > or not? > > I want to discuss whether it is beneficial to use it or not. So far I have: > > Pro: > > - Less typing > - Better readable > > which are both human-centric arguments because the actual typing > overhead is eradicated by the compiler and not present at runtime. > > Contra: > > - removes a common, well known Java idiom with something that is > unique to a library > - Library does not have a proper release but a 2008-08-20 snapshot > build as its newest version. > > which are maintainability arguments > > - Adds a static method call at every occurrence; (most of them are not > on hot paths) > > which is a technological argument > > And I want to find out whether the first two really outweigh the latter > three. > > IAW: I want an architectural discussion. And I want a decision whether > one should fade such a change into a code base > or just use a blanket replacement. I fully agree with the benefits of > readability that Kevin showed but I don't agree that > > Map<String, Integer> foo = new HashMap<String, Integer>() should be > replaced with a g-c call. > > And I want this discussion in the open, not "I work with people, we > decided, done" type discussions. > > Ciao > Henning > > > > > > On Jan 9, 2009, at 5:02 PM, Henning Schmiedehausen wrote: > > > >> On Wed, Jan 7, 2009 at 23:38, Paul Lindner <[email protected]> wrote: > >>> > >>> On Jan 7, 2009, at 5:14 PM, Henning Schmiedehausen wrote: > >>> > >>>> I -1 this patch unless you can sufficiently explain why e.g. > >>>> > >>>>> - tokenData = new HashMap<String, String>(5,1); > >>>>> + tokenData = Maps.newHashMapWithExpectedSize(5); > >>>> > >>>> is better readable to someone with knowledge of the standard Java APIs > >>>> and no knowledge of Google Collections. > >>> > >>> Is it really that hard to understand? Really? Some Junior Devs looked > >>> at > >>> that code and easily understood the intent. > >> > >> Everything needed has been said by Eric. He is smart and correct. > >> > >> I stand by my -1 I would still appreciate a compelling explanation, > >> why this is needed. > >> > >> Ciao > >> Henning > > > > >
