Mailing-List: contact dev-help@click.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@click.apache.org
Message-ID: <298047911.65291267698627175.JavaMail.jira@brutus.apache.org>
Date: Thu, 4 Mar 2010 10:30:27 +0000 (UTC)
From: "Andrey Rybin (JIRA)" <jira@apache.org>
To: dev@click.apache.org
Subject: [jira] Commented: (CLK-636) Replace
 EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
 java.util.concurrent.ConcurrentHashMap
In-Reply-To: <190398194.4621267525047199.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841170#action_12841170 ] 

Andrey Rybin commented on CLK-636:
----------------------------------

+1 for ConcurrentHashMap 

>I have tried this before and it caused strange object instantiation errors with Spring. I was not able to determine the underlying cause. 

May be It was Spring bug (Click should support v2 and up)?

Spring use ConcurrentHashMap internally.

Since 3.0 their own wrapper is deprecated

quote:
 * @deprecated as of Spring 3.0, since standard {@link java.util.concurrent.ConcurrentMap}
 * is available on Java 5+ anyway 

> 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
>         Attachments: concurrentreader_patch.diff
>
>
> 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.