Replace EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
------------------------------------------------------------------------------------------------------------
Key: CLK-636
URL: https://issues.apache.org/jira/browse/CLK-636
Project: Click
Issue Type: Improvement
Components: core
Affects Versions: 2.2.0
Reporter: Henry Saputra
Since Click required Java SDK 1.5 or later, we could leverage the
java.util.concurrent.ConcurrentHashMap class to replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class so reducing the
Click runtime dependency.
In my opinion here are some good reasons why:
1. The ConcurrentHashMap class in Java SDK is more efficient since it utilizes
internal hash classes to support better granularity and concurrency compare to
simple syncrhonized on the instance like in
DU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.
2. Looking at the use case ConcurrentReaderHashMap in Click, it used to cache
the OGNL expression (please correct me if I am wrong). This scenario does not
need exclusive lock on update which is the intended/ preferred use case for
ConcurrentReaderHashMap. If there is a miss on OGNL expression on a name in the
cache, it will cerate one and put it to the map if no other thread has not. So
it will still perform as well as or better locking entire table. However, if we
do need exclusive lock on update, we can simulate ConcurrentReaderHashMap with
ConcurrentHashMap by setting concurrencyLevel to one.
3. The ConcurrentHashMap support generic which is part of task being done to
move Click code to Java generics.
4. Looks like the EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap
class is created by Doug Lea before contributions to java.util.concurrent
packages in Java 1.5 SDK so the code may no longer optimized.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
