[concurrency-interest] jsr166y classes now in jdk7m5
alexdmiller at yahoo.com
Sun Nov 15 22:16:27 EST 2009
Makes sense to me. We've definitely felt the need for the CRHM stuff at Terracotta and usually have either used MapMaker or rolled our own. I'd love to have something like that in the JDK, but I know how these software things go...
It definitely seems challenging to me to build a concurrent LRU that is flexible enough to cover the range of common use cases while not turning it into a full-fledged cache ala Ehcache.
>From: Martin Buchholz <martinrb at google.com>
>To: Doug Lea <dl at cs.oswego.edu>
>Cc: Alex Miller <alexdmiller at yahoo.com>; concurrency-interest at cs.oswego.edu
>Sent: Sun, November 15, 2009 8:14:01 PM
>Subject: Re: [concurrency-interest] jsr166y classes now in jdk7m5
>On Sun, Nov 15, 2009 at 13:51, Doug Lea <dl at cs.oswego.edu> wrote:
>Alex Miller wrote:
>>>>>I'm guessing from this message
>>>>>>that stuff like ConcurrentReferenceHashMap / MapMaker or the concurrent LRU
>>>>>>work won't make it into JDK 7?
>>* I don't think we have much consensus yet on which replacement
>>>>policies (pseudo-LRU etc) are amenable to standardized
>>>>library support and/or how to allow plugging in more
>>>>specialized forms like those that Bob Lee, Kevin Bourrillion,
>>>>and friends have been working on for Google collections.
>Caching is hard to get right, and the Google classes are still in development.
>There definitely will be solutions for everyone to use,
>>but they will be part of a third-party package from Google.
>I agree with Doug that it seems too early to try to standardize them now.
>Integrating them into JDK8 seems more realistic.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest