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]

Reply via email to