Why not compare e.key directly instead of assigning it to a variable?

Question

While reading the source code for HashMap, I came across this snippet in public V put(K key, V value):

for (Entry<K,V> e = table[i]; e != null; e = e.next) {
    Object k;
    if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
        V oldValue = e.value;
        e.value = value;
        e.recordAccess(this);
        return oldValue;
    }
}

Why assign e.key to k for comparing? Why not compare directly, like:

if (e.hash == hash && (e.key == key || key.equals(e.key))

------------------- UPDATE ------------------------

According to the answer from @seand, I do more detail investigation:

import com.test.Test;

    public class Main {
        public static void main(String[] args) {
            Test t = new Test();
            int a = t.a;
            int b = a;
        }
    }

class Test has a int filed a;

Using javap -c Main to get the class file content:

  public static void main(java.lang.String[]);
Code:
   0: new           #2                  // class test/Test
   3: dup           
   4: invokespecial #3                  // Method test/Test."<init>":()V
   7: astore_1      
   8: aload_1       
   9: getfield      #4                  // Field test/Test.a:I
  12: istore_2      
  13: iload_2       
  14: istore_3      
  15: return    

int a = t.a represents

8:[load the t object]
9:[access the field a]
12:[store the value to a]

Refer to jvm specification get information of [getfield]

int b = a represents:

13:[load the local variable]
14:[store the value to b];

It seems reasonable to access the local variable than the class field.

Answer 1

My guess is it's an optimization which saves an extra lookup to e.key. (Though it's not actually a method call that's using invokevirtual, it may save a level of indirection). Since this is a very heavily used library function the authors likely used every trick they could think of for maximum performance. You can also see how it checks for object identity in k = e.key which may avoid a slightly more costly equals() call.