Canonicalizing mapping in a WeakHashMap

Question

What a canonicalizing container is?
Maybe one that stores unique objects. Unique objects in the sense that their equivalence is only established via ==, not based on the state?
In the API for WeakHashMap :
" This class is intended primarily for use with key objects whose equals methods test for object identity using the == operator. Once such a key is discarded it can never be recreated, so it is impossible to do a lookup of that key in a WeakHashMap at some later time and be surprised that its entry has been removed. This class will work perfectly well with key objects whose equals methods are not based upon object identity, such as String instances. With such recreatable key objects, however, the automatic removal of WeakHashMap entries whose keys have been discarded may prove to be confusing."
What sort of confussion is this?
Only that the programmer may be expecting that a recreatable object could be still in the map after having been discarded and recreated?

Answer 1

I was trying to make sure which the confussion was
because I found strange that anybody could be
surprised by a WeakHashMap doing its job.A WeakHashMap has the potential to cause confusion in the unwary programmer, for example
WeakHashMap map = new WeakHashMap();
map.put("Key", "Value");
System.out.println(map.get("Key"));If garbage was collected between the put and get calls, the "Key" -> "Value" mapping may have been collected (There are no references to "Key", except in the internal string pool). Seeing the program print out a null for the map get request is non-intuitive, which is the most likely source of confusion.
But now I think that this is similar to the behaviour
of a WeakReference Object as well. So why not using an
array of WeakReference objects intead?The usual reason for choosing a map over an array is for speed performance.
"The containers library has a special Map to hold weak
references: the WeakHashMap. This class is designed to
make the creation of canonicalized mappings easier. In
such a mapping, you are saving storage by making only
one instance of a particular value. When the program
needs that value, it looks up the existing object in
the mapping and uses that (rather than creating one
from scratch)."
So we should save space by making only one instance of
a particular value. What would prompt us to make
several instances of a value ? Copies of the same
object I suppose, otherwise it should have said
several instances of a class.I think it meant (?) to mean 'only one instance of a particular value class.', since you can only put objects in a map.
From the last sentence
it is inferred if not using this technique we should
be creating the object each time is used. Why?I think you are improperly negating this. My interpretation of the last sentence is that this is one method for preventing recreating objects that are used more than once. There may be other methods for doing this, they simply aren't covered by the statement.
To answer the second question, it may be preferable to create an object in each place it is used if the object is mutable - if the object is shared between two threads, then its contents may be unexpectedly changed by the other thread, causing strange errors.
I can tell, however, a difference between using
WeakReference array and a WeakHashMap.
In the former the point is to use an object as long as
it is not memory shortage. In the latter the point is
a kind of unique relation between the key and the
value (this my guess at least), but if there wasn't
any outside references to the values the behaviour is
very similar to the former. Continuing with this
though, if there was outside references to the value,
our aim wouldn't be saving memory but a relation
between the key and the value that would come to an
end when memory shortage occurred. Any use for this
possible feature?The most appropriate use for this I have seen is in implementing a memory cache. As long as memory doesn't become tight, repeated requests run blindingly fast. Well, at least compared to some operations such as File I/O, if in the context of caching file contents in memory.
Enough from me.
-Troy