[infinispan-dev] A better fix for Immutables

Wed Sep 23 19:06:11 EDT 2009

The one (unpleasant) way to use libraries and avoid version hell:
create localised version/named version (either by refactoring, if
licence allows it) or jarjar type tools. Not ideal - but common with
things like asm or antlr runtime (they aren't big).

BUT, it does ad weight to your code.

As a scala fanboy (yes I will admit) this is a weakness of it as well
- it has as portly runtime library (3meg at the moment) that has
wonderous things (much more then google collections) but you would NOT
use it lightly.

In theory - isn't OSGi supposed to help with the version hell as well?
Obviously if we are exposing said collections to outside world, it
won't help, but for internal use, there are options.

Although, at this stage, for Infinispan (which is built on mature
foundations) I also think its overkill (and Jason would know) for
greenfields, maybe...

On Thu, Sep 24, 2009 at 8:27 AM, Jason T. Greene
<jason.greene at redhat.com> wrote:
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com