Proposal: Delay deprecation of MapMaker

[Gili Tzabari]

I just noticed that MapMaker's write functions (e.g. expireAfterWrite)
are deprecated and scheduled for removal in Guava 11. Contrary to what
the documentation says, you can't really use CacheBuilder as a
replacement because Cache.put() is missing (what's the point of
expireAfterWrite without it?).

I'd like to suggest pushing back deprecation of these methods until
one major version after Cache.put() is added.

Gili

[Ted Yu]

+1 on this proposal.

We need Cache.put()

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss

This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

[peter]

It still works, since it hasn't been removed. By marking it as
deprecated it stops new code being written that uses it. I think it's
more responsible to mark something as deprecated as soon as possible.

Ask for more time before removal if you need it.

[Louis Wasserman]

I'm actually...semi-convinced.  I understood that Cache.put would come around in release 11, but as I understand it, that doesn't leave you guys any release in between during which you can migrate from MapMaker to Cache.put.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

[Charles Fry]

I just noticed that MapMaker's write functions (e.g. expireAfterWrite)
are deprecated and scheduled for removal in Guava 11. Contrary to what
the documentation says, you can't really use CacheBuilder as a
replacement because Cache.put() is missing (what's the point of
expireAfterWrite without it?).

"writes" occur whenever new values are loaded into the cache from your CacheLoader. We strongly believe that most of the time caches are more cleanly abstracted with no manual writes, only internal writes of values fetched from the CacheLoader. I'd love to better understand why so many people want manual writes so bad! We agree that there are times when they're necessary, but we'd like to believe manual writes unnecessary in many common cases.

 

I'd like to suggest pushing back deprecation of these methods until
one major version after Cache.put() is added.

I think we should consider that, as well as consider adding support for Cache writes in the next point release. But again, please help us understand the use cases that are driving this panic!

Charles

[cowwoc]

1. As far as I can tell, there are no major problems with the MapMaker methods.
   
2. As far as I can tell, there is no reasonable replacement for the MapMaker methods.
3. I agree that it's responsible to encourage users to migrate as soon as possible, but currently the deprecation is doing nothing more than annoying me with IDE warnings (why are you using deprecated methods?!) and misleading users into believing that Cache can handle writes, when in fact it cannot.

    If I could, I'd remove the deprecation on MapMaker and the existence of Cache.expireAfterWrite(). They are misleading until Cache.asMap().put() is added. Baring that, I'd extend deprecation by an extra release.

Gili

[cowwoc]

On 30/09/2011 6:09 PM, Charles Fry wrote:

I just noticed that MapMaker's write functions (e.g. expireAfterWrite)
are deprecated and scheduled for removal in Guava 11. Contrary to what
the documentation says, you can't really use CacheBuilder as a
replacement because Cache.put() is missing (what's the point of
expireAfterWrite without it?).

"writes" occur whenever new values are loaded into the cache from your CacheLoader.

    Good point, so Cache.expireAfterWrite() isn't totally useless in version 10. I stand corrected. Still, the documentation for MapMaker.expireAfterWrite() should mention it's not a perfect replacement at this time (because it's missing manual writes).

We strongly believe that most of the time caches are more cleanly abstracted with no manual writes, only internal writes of values fetched from the CacheLoader. I'd love to better understand why so many people want manual writes so bad! We agree that there are times when they're necessary, but we'd like to believe manual writes unnecessary in many common cases.

 

I'd like to suggest pushing back deprecation of these methods until
one major version after Cache.put() is added.

I think we should consider that, as well as consider adding support for Cache writes in the next point release. But again, please help us understand the use cases that are driving this panic!

Charles

    This is probably not the best use-case in the world, but here is something I just ran into... I am implementing a Genetic Algorithm. I want to use Map<Genome, Age> to keep track of how long a "genome" has been around. The longer a genome is found in the population, the more likely it contributed to positive fitness. Every generation I want to update this Map (incrementing the age of genomes found in the population). Because the search-space of possible genomes is huge I want keys to expire after 10 seconds.

    Essentially I am looking up keys in a Map, and increment the values (manual writes). Keys that are not accessed in a while should be removed.

Gili

[Charles Fry]

As far as I can tell, there are no major problems with the MapMaker methods.

I assume you mean the cache-related MapMaker methods. Basically we've come to the conclusion that MapMaker is the wrong abstraction for caching. It will remain for what it does best (imagine MapMaker from release 7.0 minus makeComputingMap), but we're taking caching in a different direction. 

As far as I can tell, there is no reasonable replacement for the MapMaker methods.

It is true that we need to support some form of write in CacheBuilder before we can deprecate MapMaker.makeComputingMap. That probably implies that we need to keep around the other cache-related methods for the same reason. Sure. 

I agree that it's responsible to encourage users to migrate as soon as possible, but currently the deprecation is doing nothing more than annoying me with IDE warnings (why are you using deprecated methods?!) and misleading users into believing that Cache can handle writes, when in fact it cannot.

Well, we are deprecating it so that you know it is going to be deleted. If that has led you to communicate your concerns with that to us, then it was _clearly_ the right thing to do. 

    If I could, I'd remove the deprecation on MapMaker and the existence of Cache.expireAfterWrite(). They are misleading until Cache.asMap().put() is added. Baring that, I'd extend deprecation by an extra release.

Point taken. At this point I'm favoring a point release to get asMap.put out there.

Charles

 

[Maaartin G]

On Oct 1, 12:29 am, cowwoc <cow...@bbs.darktech.org> wrote:
>      This is probably not the best use-case in the world, but here is
> something I just ran into... I am implementing a Genetic Algorithm. I
> want to use Map<Genome, Age> to keep track of how long a "genome" has
> been around. The longer a genome is found in the population, the more
> likely it contributed to positive fitness. Every generation I want to
> update this Map (incrementing the age of genomes found in the
> population). Because the search-space of possible genomes is huge I want
> keys to expire after 10 seconds.
>
>      Essentially I am looking up keys in a Map, and increment the values
> (manual writes). Keys that are not accessed in a while should be removed.

I surely wouldn't call it "caching" and IMHO it's one of the cases
when an expiring Map is needed (and not a cache).

I just wondered why you couldn't remember the creation time instead of
computing the age. But I think you need it because of genomes
reappearing in the population (so it's a sort of computing the
frequency/occurrences)?

[cowwoc]

Yes, I agree this is an expiring map. And yes, genomes reappear in
the population so this is a matter of frequency/occurrences.

Gili

[Charles Fry]

I just pulled support for Cache.asMap().put (and other write operations) into the release branch. It'll be out by the end of the week.

Charles

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss

This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry

[Tim Peierls]

Excellent news!

[Kevin Bourrillion]

And by "by" the end of the week, we mean "at" the end of the week.  We seem to be getting a much better stream of feedback after 10.0 went final, which is telling me that not enough users really tried out the release candidates.  (But thanks to those who did!)  And that has me thinking we'll likely hear about more unexpected, possibly patch-worthy issues over the coming days.

Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com