As we see in source ordering operation takes place when we put some
K(key), V(value) into MapTee:

public V put(K key, V value) {
       Entry<K,V> t = root;

       if (t == null) {
           incrementSize();
           root = new Entry<K,V>(key, value, null);
           return null;
      }

       while (true) {
           int cmp = compare(key, t.key);   // in this point we have
comparing operation
           if (cmp == 0) {
               return t.setValue(value);
           } else if (cmp < 0) {
               if (t.left != null) {
                   t = t.left;
               } else {
                   incrementSize();
                   t.left = new Entry<K,V>(key, value, t);
                   fixAfterInsertion(t.left);
                   return null;
               }
           } else { // cmp > 0
               if (t.right != null) {
                   t = t.right;
               } else {
                   incrementSize();
                   t.right = new Entry<K,V>(key, value, t);
                   fixAfterInsertion(t.right);
                   return null;
               }
           }
       }
   }

So as we see there are comparing only by K if  you want to compare by
value to , create your own class (MyTreeMap extends TreeMap) and
override   "put" method,
In this case you will have class which compares V.

Darko Aleksic schreef:

Jakarta Commons Collections[*] has a SortedBidiMap, where both keys and
values are sorted.  Though I do not understand what you mean by ‘put
them back in’ after they are sorted.  This will loose the sorting.
Unless you use a LinkedHashMap, perhaps that is what you want?

Cheers, H.

[*] Unfortunately, not generified yet.  The discussion is ongoing.
There is a nice Sourceforge project which has generic versions of most
of it: larvalabs.com.
- --
Hendrik Maryns

==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

I guess you could look up the value from the key in the tree. Might be
more safe to look it up in another copy of the map. You might want to
use a SortedSet for the sorting and another map for the key lookup.

A common hack is to add extra data onto the key which isn't used for
testing equality.

Entries do not necessarily work with Compartors. Some entry sets may
return the same Map.Entry object just with different values. So when
comapre(Entry<Key,Value>,Entry<Key,Value>) is called, both arguments are
the same object. You should be alright with HashMap and TreeMap, but not
IdentityHashMap.

Yes. In fact it's a good idea to make keys immutable.

Tom Hawtin