commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [beanutils] PROPOSAL: eliminate core dependency on collections
Date Sat, 08 May 2004 06:14:38 GMT
Shapira, Yoav wrote:

>I have another question to toss into this discussion, specific to
>FastHashMap: is it still useful in the first place?  Could it be that
>with today's hardware and recent JVM implementation, Java's built-in
>HashMap is good enough for the needs of beanutils and/or struts?
>Yoav Shapira
Historical note:  the Fast* classes, and [beanutils] and [digester], 
were originally part of Struts 1.0's utility classes, and were 
contributed to Commons because they are generally useful.

The interesting use case in Struts and [beanutils] is the following:  in 
most application environments, you generally load up a bunch of 
configuration stuff at the very beginning of your application (during 
context initialization in a webapp), and then use it over and over again 
while the app executes.  As you know, collection classes like HashMap 
are *not* thread safe; therefore, they are safe for multithread access 
only if you synchronize around every access (either read or write), or 
if there are no modifications to the collection while the application is 

However, real life says that such collections are *not* always immutable 
during the lifetime of the application.  (This is particularly true for 
[beanutils], which caches the metadata about a particular Java class the 
first time that introspection is performed on it, and that can happen at 
any time.)  The conservative/safe approach would be to synchronize 
around every get() call on the collection, but this has *significant* 
performance impacts.

The Fast* series of collections were designed to allow access that 
doesn't require any synchronization around get() calls in the 99.9% use 
case, while still respecting the fact that the underlying collections 
are really not thread safe.  If you can show me that synchronization on 
"recent JVM implementations" is so good that it has zero performance 
impact on that 99.9% use case, I would agree with you that the Fast* 
classes are no longer needed.  However, I remain a skeptic in that regard.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message