Why does computingMap support identity equality for keys against equals()?

[Pangea]

I've been reading that ComputingMap only supports identity equality
and not the equals(). Can someone clarify why?

[Kevin Bourrillion]

Hello Pangea,

First, to clarify the behavior:  if you choose .weakKeys() or .softKeys(), then keys are compared using identity.  Otherwise, keys are compared using object equality.  And choosing weak or soft _values_ doesn't change the way keys are compared.
It's like this because, in my opinion, it's the only way that makes any sense.

Let's say you have a cache with weak keys of type Long, and the value 12345 is mapped to some value in the cache. You would like this value to be returned for *any* Long with value 12345, not just the one that was used to store it.

Which of these behaviors would you expect to happen?

(a) this entry is reclaimed once *any* reference to a Long with value 12345 is reclaimed.
(b) this entry is reclaimed only once *all* references to Longs with value 12345 are
reclaimed.

Whoops -- actually (b) is quite infeasible, so we're left with (a).  But (a) is arbitrary and makes no sense - -the act of *some* object with that value being gc'd is a pretty irrelevant occurrence.

If you can give us more information about what you're trying to do, perhaps we can help further.  Here's the most recent bug that was asking for this (its requester ultimately realized he actually meant to use softValues):

http://code.google.com/p/google-collections/issues/detail?id=250&can=1&q=mapmaker

On Tue, Jan 26, 2010 at 8:39 AM, Pangea <yara...@gmail.com> wrote:

I've been reading that ComputingMap only supports identity equality
and not the equals(). Can someone clarify why?

--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

--
Kevin Bourrillion @ Google
internal:  http://go/javalibraries
external: guava-libraries.googlecode.com

[Pangea]

Thx for the clarification. I think it would be a nice feature if the
computingMap can take an expiration strategy. Here is the usecase.

for each thread ((3 independent threads, each thread working on a
particular type of input)
{
read input

if (correlation-id is already generated for this input)
{
lookup the correlation-id from the cache;
return correlation-id;
}
else
{
generate the correlation-id;
cache it;
return correlation-id;
}
}

~Cleanup thread~

if(correlation id is used 3 times)
{
then clear it from the map
}

Constraints: - The number of input records can go till 500K (for each
input type) so doesn't want to use strong references. - Doesn't want
to generate one-way hashes as of now (i know that if we use one-way
hash then there is no need to cache)

[Kevin Bourrillion]

Interesting -- once it's used three times, that's when it should become eligible for cleanup?  I'd never thought of a policy like that.

--

guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com

This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".

[Pangea]

yes...because the correlation id is there to correlate 3 inputs only
and if there are 4 inputs then it should be expired after 4
reads....whole point is each ones expiration policy might be
different...hence the pluggable expiration policy

> > unsubscribe: guava-discus...@googlegroups.com<guava-discuss%2Bunsubscribe@goog legroups.com>

[Pangea]

so do u think this can be achieved in someway with the existing map
maker? and if not can this feature be included in ur road map?