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 <[email protected]> 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 <[email protected]> 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: [email protected] >>>> To: [email protected] >>>> 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:[email protected]] >>>> Sent: Tuesday, November 02, 2010 11:41 AM >>>> To: [email protected] >>>> 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: [email protected] >>>>> Date: Tue, 2 Nov 2010 11:32:01 -0600 >>>>> To: [email protected] >>>>> >>>>> 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 >>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> ________________________________________ >>>>>>> From: [email protected] [[email protected]] On >>>>>>> Behalf Of James Carman [[email protected]] >>>>>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
