Shapira, Yoav wrote:

Hi,
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 running.

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.

Craig


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to