[
https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840583#action_12840583
]
Joseph Schmidt commented on CLK-636:
------------------------------------
> I have tried to deploy the click-examples and looks like it run well. ...
Henry,
If you take a look at the Click history:
http://click.apache.org/docs/roadmap-changes.html
you will see that it's since 2005 (for the public) around, and so, there are
many commercial applications that depend on it and it's stability.
It's not that simple as just to change something and see if click-examples work
:).
The base of Click applications in production is very very important and this is
why backward compatibility and stability is key when considering updates to
Click: many "cool" requests(even with patches) were refused because of this.
> 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.
