You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Daniel Sun (JIRA)" <ji...@apache.org> on 2019/02/05 14:10:00 UTC

[jira] [Updated] (GROOVY-8981) Make groovy internal maps based on JDK maps

     [ https://issues.apache.org/jira/browse/GROOVY-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Sun updated GROOVY-8981:
-------------------------------
    Summary: Make groovy internal maps based on JDK maps  (was: Make groovy maps based on JDK maps)

> Make groovy internal maps based on JDK maps
> -------------------------------------------
>
>                 Key: GROOVY-8981
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8981
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Daniel Sun
>            Priority: Major
>
> See the discussion from github: [https://github.com/apache/groovy/pull/860#issuecomment-460484213]
> [~blackdrag] said:
> {code:java}
> My personal analysis on this is the following.... as long as count is only changed within a lock/unlock sequence volatile should be good enough. But the rehash methods do not guarantee that. But then again the implementation would be broken if they do not lock on rehash... actually I wonder who is actually calling that method.
> My conclusion: Get rid of these classes. Java's concurrent hash map provides much better functionality, much better tested and afaik with a better performance profile.
> {code}
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)