Something else to consider is Stephen Colebourne's Joda Primitives: http://joda-primitives.sourceforge.net/
Commons Primitives hasn't been touched since 2005 when Stephen was active on the component. I think it's an Attic component (ie not being worked on and no future releases expected). Bcc to Commons Users; moving conversation to Dev on the 2nd point. Hen On Tue, Nov 2, 2010 at 1:52 PM, sebb <seb...@gmail.com> wrote: > Note that lack of recent activity is not necessarily a bad sign; in > this case I think it's because the code is working fine. > I could find no outstanding bugs for the component. > > On 2 November 2010 20:10, Brian Pontarelli <br...@pontarelli.com> wrote: >> I probably wouldn't use these collections in a factory context. If I'm >> concerned about speed and size, I'm going to create the primitive collection >> using the constructor and then use it directly. Adding in any factories, >> AOP, etc. is just going to add overhead. >> >> The original issue is really whether or not the commons library is still >> active or if Trove is a better choice. I'd say either library will work and >> I've used both. Another thing to think about is your comfort with licenses. >> I prefer ASL over LGPL as a rule of thumb and Trove is LGPL. I tend to avoid >> anything with the letters G, P and L in the license. But if you can find >> something with BSD, that's the way to go. >> >> ;) >> >> -bp >> >> >> On Nov 2, 2010, at 1:24 PM, Martin Gainty wrote: >> >>> >>> also lookup methods from factories will reliably lookup >>> ArrayList<BoxedPrimitiveDatatype> when bean definition has attribute >>> dependency-check="object" but wont lookup a collection of primitives such >>> as int []PrimitiveDataTypeVariable even when the bean definition specified >>> dependency-check="simple" >>> >>> http://static.springsource.org/spring/docs/1.2.9/reference/beans.html >>> >>> thanks, >>> Martin Gainty >>> ______________________________________________ >>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >>> >>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >>> dient lediglich dem Austausch von Informationen und entfaltet keine >>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le >>> destinataire prévu, nous te demandons avec bonté que pour satisfaire >>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >>> de ceci est interdite. Ce message sert à l'information seulement et n'aura >>> pas n'importe quel effet légalement obligatoire. Étant donné que les email >>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >>> aucune responsabilité pour le contenu fourni. >>> >>> >>> >>> >>> >>>> From: josiah.d.hasw...@hp.com >>>> To: u...@commons.apache.org >>>> Date: Tue, 2 Nov 2010 18:42:29 +0000 >>>> Subject: RE: [Primitives] Does anyone use this? >>>> >>>> Gnu Trove includes a set of benchmarks vs. the JCF. I don't understand why >>>> this is so controversial; a developer should be able to assess the >>>> suitability of a library for his or her purposes without it turning into a >>>> huge debate. If dependency-management is an issue, Trove is available from >>>> numerous Ivy/Maven repositories. >>>> >>>> Joe H. | HP Software >>>> >>>> -----Original Message----- >>>> From: Martin Gainty [mailto:mgai...@hotmail.com] >>>> Sent: Tuesday, November 02, 2010 11:41 AM >>>> To: u...@commons.apache.org >>>> Subject: RE: [Primitives] Does anyone use this? >>>> >>>> >>>> Brian >>>> >>>> how does primitive collections implementation perform better than JDK >>>> collections? >>>> >>>> thanks, >>>> Martin >>>> ______________________________________________ >>>> please do not alter or disrupt this transmission. thank you >>>> >>>> >>>> >>>> >>>> >>>>> Subject: Re: [Primitives] Does anyone use this? >>>>> From: br...@pontarelli.com >>>>> Date: Tue, 2 Nov 2010 11:32:01 -0600 >>>>> To: u...@commons.apache.org >>>>> >>>>> I would assume once you get out of the autoboxing caches the performance >>>>> will get even worse. It really depends on the application, but I've found >>>>> a number of spots where primitive collections work much better than >>>>> autoboxing and JDK collections. >>>>> >>>>> -bp >>>>> >>>>> >>>>> On Nov 2, 2010, at 11:25 AM, James Carman wrote: >>>>> >>>>>> Yet another dependency to add to the mix. >>>>>> >>>>>> On Tue, Nov 2, 2010 at 1:17 PM, Cogen, David - 1008 - MITLL >>>>>> <co...@ll.mit.edu> wrote: >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: jcar...@carmanconsulting.com [jcar...@carmanconsulting.com] On >>>>>>> Behalf Of James Carman [ja...@carmanconsulting.com] >>>>>>> Sent: Tuesday, November 02, 2010 12:30 PM >>>>>>> To: Commons Users List >>>>>>> Subject: Re: [Primitives] Does anyone use this? >>>>>>> >>>>>>> Premature optimization with JDK5. I'd say stick to the JDK classes if >>>>>>> you can and only try to beef up space/performance if you need to. >>>>>>> >>>>>>> >>>>>>> Normally I agree about evils of premature optimization. But >>>>>>> ArrayListInt is practically a drop-in replacement for >>>>>>> ArrayList<Integer> and I see no reason not to use it if it is supported >>>>>>> and reliable. >>>>>>> >>>>>>> My test of 2 billion accesses (reads and writes) ran in 35% of the time >>>>>>> when I used ArrayListInt vs. ArrayList<Integer>. >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: user-h...@commons.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: user-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: user-h...@commons.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: user-h...@commons.apache.org >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org