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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)atm.com.pl <mailto:Krzysztof.Sobolewski@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/infinispan-dev ------------------------------------------------------------------------ _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)atm.com.pl >> <mailto:Krzysztof.Sobolewski@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org >> > >>    https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org&gt; 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(a)atm.com.pl >>>> <mailto:Krzysztof.Sobolewski@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(a)lists.jboss.org <mailto:infinispan-dev@lists.jboss.org >>>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> -- >> Manik Surtani >> manik(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Jason T. Greene 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. +1000 For my taste, Infinispan has way too many dependencies already !

> So every dep needs to offer significant functionality to justify its > existence, and a few small collection classes don't really do that. Exactly > Whereas depending on something like a network communication layer, > that > is over a hundred thousand lines of code makes sense. Ha ha got you :-) -- Bela Ban Lead JGroups / Clustering Team JBoss _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 09/24/2009 12:50 PM, Manik Surtani wrote: > > </snip> > > For a basic runtime, the deps are fairly limited (JTA interfaces, > JGroups, JBoss Marshalling if you are using JDK6. Add JAXB if JDK5) Hmmm, JBoss Marshalling if you are using JDK6? JBoss Marshalling is there regardless AFAIK and has JDK5 requirements. It's XNIO 2.0 that might have JDK6 requirement but it'd be in an optional module anyway.

On 09/25/2009 07:38 AM, Manik Surtani wrote: > On 25 Sep 2009, at 11:53, Galder Zamarreno wrote: >> On 09/24/2009 12:50 PM, Manik Surtani wrote: >>> >>> </snip> >>> >>> For a basic runtime, the deps are fairly limited (JTA interfaces, >>> JGroups, JBoss Marshalling if you are using JDK6. Add JAXB if JDK5) >> >> Hmmm, JBoss Marshalling if you are using JDK6? JBoss Marshalling is >> there regardless AFAIK and has JDK5 requirements. It's XNIO 2.0 that >> might have JDK6 requirement but it'd be in an optional module anyway. > > I should have added brackets. :-) > > "{JTA interfaces, JGroups, JBoss Marshalling} if you are using JDK6. > Add JAXB if JDK5." Also it seems foregone that a (relatively-near) future JBMAR will require JDK6, namely to add support for optimized serialization of new collection types and to take advantage of the faster classloading of JDK6-targeted classes.

- DML _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 25 Sep 2009, at 16:56, Galder Zamarreno wrote: > > > On 09/25/2009 05:38 PM, David M. Lloyd wrote: >> On 09/25/2009 07:38 AM, Manik Surtani wrote: >>> On 25 Sep 2009, at 11:53, Galder Zamarreno wrote: >>>> On 09/24/2009 12:50 PM, Manik Surtani wrote: >>>>> >>>>> </snip> >>>>> >>>>> For a basic runtime, the deps are fairly limited (JTA interfaces, >>>>> JGroups, JBoss Marshalling if you are using JDK6.  Add JAXB if >>>>> JDK5) >>>> >>>> Hmmm, JBoss Marshalling if you are using JDK6? JBoss Marshalling is >>>> there regardless AFAIK and has JDK5 requirements. It's XNIO 2.0 >>>> that >>>> might have JDK6 requirement but it'd be in an optional module >>>> anyway. >>> >>> I should have added brackets.  :-) >>> >>> "{JTA interfaces, JGroups, JBoss Marshalling} if you are using JDK6. >>> Add JAXB if JDK5." >> >> Also it seems foregone that a (relatively-near) future JBMAR will >> require >> JDK6, namely to add support for optimized serialization of new >> collection >> types and to take advantage of the faster classloading of JDK6- >> targeted >> classes. > > Hmmm, this is important since JBMAR is a core dependency. We had a > discussion a while back and the agreement was to stay on JDK5 since we > did nothing JDK6 specific but I think it might be time to move to JDK6 > fully, thoughts? Vote to the public?  I'd love to baseline on JDK6.  But I'd hate to limit uptake. Cheers -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I think most enterprises will react to the EOL of JDK 5. For example, when JDK 1.4 was EOL, almost all applications in a medium sized enterprise I worked in were on JDK 5 within a year. One limiting factor in uptake time was the maturity of appservers that supported the new JDK. In today's context, JDK 6 compatible appservers and frameworks have been available for over a year already, and past their .0 release. I agree that embracing infinispan would imply reasonably fresh thinking and already place it into a dev team who are probably already on JDK 6. I moreover doubt any enterprise would issue a policy enforcing use of an EOL JDK, so these fresh thinking dev teams will not likely encounter problems moving to prod.

at the end of that ramble.... +1 release with JDK 6+ support Cheers, Adrian jclouds On Sat, Sep 26, 2009 at 5:57 AM, Sanne Grinovero <sanne.grinovero(a)gmail.com > wrote: My 2c: I'm deploying only on JDKs >=6 since three years now, and IMHO new projects going to consider Infinispan in this timeframe are probably in a design/early development fase, almost everyone will be ready to deploy something stable only after the JDK5 will be phased out. The main "market" for this kind of libraries is enterprise, which wants support and will probably refrain from using Java5, at least for new deployments. 2009/9/26 Manik Surtani <manik(a)jboss.org&gt;: > > On 25 Sep 2009, at 16:56, Galder Zamarreno wrote: > >> >> >> On 09/25/2009 05:38 PM, David M. Lloyd wrote: >>> On 09/25/2009 07:38 AM, Manik Surtani wrote: >>>> On 25 Sep 2009, at 11:53, Galder Zamarreno wrote: >>>>> On 09/24/2009 12:50 PM, Manik Surtani wrote: >>>>>> >>>>>> </snip> >>>>>> >>>>>> For a basic runtime, the deps are fairly limited (JTA interfaces, >>>>>> JGroups, JBoss Marshalling if you are using JDK6. Add JAXB if >>>>>> JDK5) >>>>> >>>>> Hmmm, JBoss Marshalling if you are using JDK6? JBoss Marshalling is >>>>> there regardless AFAIK and has JDK5 requirements. It's XNIO 2.0 >>>>> that >>>>> might have JDK6 requirement but it'd be in an optional module >>>>> anyway. >>>> >>>> I should have added brackets. :-) >>>> >>>> "{JTA interfaces, JGroups, JBoss Marshalling} if you are using JDK6. >>>> Add JAXB if JDK5." >>> >>> Also it seems foregone that a (relatively-near) future JBMAR will >>> require >>> JDK6, namely to add support for optimized serialization of new >>> collection >>> types and to take advantage of the faster classloading of JDK6- >>> targeted >>> classes. >> >> Hmmm, this is important since JBMAR is a core dependency. We had a >> discussion a while back and the agreement was to stay on JDK5 since we >> did nothing JDK6 specific but I think it might be time to move to JDK6 >> fully, thoughts? > > Vote to the public? I'd love to baseline on JDK6. But I'd hate to > limit uptake. > > Cheers > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev