Re: New functionality in the Set<T> interface.(was: TreeSet and HashSet)
Marcin wrote:
Note that a Map, like any Collection, only stores
references and not actual object instances. If you create
an object that has a megabyte key:
class Thing {
private byte[] key = new byte[1024*1024];
...
}
... and insert it in a Map as both key and value:
Thing thing = new Thing();
map.put(thing, thing);
... there's still only one copy of the megabyte key
floating around.
When we want to put new key objects with chosen fields the problem exists
with unwrapped type like
char, int, long, float, double, etc.
... but you wrote about "very huge data, space consumed by
key object could be very big." If the key is a wrapped primitive,
it isn't "very big."
But in your solution you're right,
there is only need to store references. But i'm not sure if this solution is
safe, because we have references to the same important data from two sets
keySet and valueSet, so we have to be careful with them. Mapping object to
the same object does not have a big sense, for example what about the method
put when the key already exist, after this operation we have a map where key
and value are different, so we have inconsistent data.
But what do you provide as the second argument to put()? If
you always write put(obj,obj) there will never be any kind of
mismatch. Yes, sometimes put(obj,obj) might replace an existing
oldobj->oldobj mapping -- but if you didn't want that to happen,
you shouldn't have called put() in the first place!
As for the set of keys and the set (collection, really) of
values, yes: you must "be careful with them." But this is no
different from being "careful" with the members of a Set! If you
add a mutable object to a Set and then mutate it in a way that
violates the Set's requirements, you're already in trouble. Using
a Map doesn't make things worse in any way I can think of.
I'm not sure is
this concept is perfect. For example in the implementation of sets java
language developers were used mapping from object to dummy object instead of
object to the same object, maybe there were some important reasons?
Maybe. It might be nothing more than a convenience: using a
special object as the "value" makes it easy to allow null as an
actual member of the set.
--
Eric Sosman
esosman@acm-dot-org.invalid