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: user@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: user@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: user@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
> 
                                          

Reply via email to