[infinispan-dev] A better fix for Immutables

[Jason T. Greene]

Dependencies have significant impact on public projects. Every 
dependency added is another possible version conflict with someone's 
environment. You are also locked into whatever that dependency does, so 
if you need to fix/customize something in the dep, you sometimes have to 
patch and ship your own version. It also annoys users when a project 
they uses sucks in N libraries, which each include N more, ad infinitum. 
We have had issues with this in the past, and have tried to reduce where 
possible.

So every dep needs to offer significant functionality to justify its 
existence, and a few small collection classes don't really do that. 
Whereas depending on something like a network communication layer, that 
is over a hundred thousand lines of code makes sense.

I don't see how not using google collections makes infinispan less 
compatible with some future unknown jdk enhancement. It would be in a 
different package. Further anytime anything gets submitted and added to 
the JDK it tends to go through major revision, so even if the google 
stuff makes it through, it will likely look different.

The one aspect that could potentially be convincing, is if we wanted to 
support exposing inifnispan as a google collection, which would allow 
users of google collections to interact with infinispan in a similar 
way. I'm not sure if there are enough people that would want to do this, 
or how well the api maps to a distributed map.

Jeff Ramsdale wrote:
> I won't insist. But I think less code to maintain is a Good Thing.
> Even "a few lines of code" (per Jason) can contain sneaky bugs. Poke
> through the Google Collections API
> (http://google-collections.googlecode.com/svn/trunk/javadoc/index.html),
> there's some great stuff in there: Predicates and Functions that can
> be applied to Collections, MultipMap, as well as their BiMap. The
> latter, in particular, is worth paying attention to if it becomes a
> Java standard and Infinispan's similar, but different, implementation
> is incompatible.
> 
> -jeff
> 
> On Wed, Sep 23, 2009 at 10:00 AM, Manik Surtani <manik at jboss.org> wrote:
>> On 8 Sep 2009, at 22:19, Jason T. Greene wrote:
>>
>>> IMO it's not worth adding another dep for something that can be
>>> created
>>> in a few lines of code.
>> Yeah unless I have a real reason to do so, I'm not adding google
>> collections.
>>
>>
>>> Jeff Ramsdale wrote:
>>>> Yeah, I noticed the same thing. I was thinking of suggesting the
>>>> use of
>>>> Google Collections, too: http://code.google.com/p/google-collections/
>>>>
>>>> They provide a host of Immutable collections and many other handy
>>>> classes. Specifically, I thought BiMap could replace BidirectionalMap
>>>> (I've been working on implementing this, actually). The Google
>>>> Collections are very well tested (and widely deployed), vetted by
>>>> Josh
>>>> Bloch, and may potentially make it into the JDK in time.
>>>>
>>>> Great interview with the creators
>>>> here: http://www.javalobby.org/articles/google-collections/
>>>>
>>>> -jeff
>>>>
>>>> On Fri, Sep 4, 2009 at 11:30 PM, Krzysztof Sobolewski
>>>> <Krzysztof.Sobolewski at atm.com.pl
>>>> <mailto:Krzysztof.Sobolewski at atm.com.pl>> wrote:
>>>>
>>>>    I noticed that there was a problem with generics in Immutables
>>>>    class. May I
>>>>    suggest a better approach? (patch attached) :)
>>>>
>>>>    [AFAICS the same thing is needed for analogous code in JBoss
>>>> Cache, BTW]
>>>>    -KS
>>>>
>>>>    _______________________________________________
>>>>    infinispan-dev mailing list
>>>>    infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org
>>>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Jason T. Greene
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Jason T. Greene
JBoss, a division of Red Hat