Why does autoboxing not use valueOf() when invoking via reflection?

The cited part has been rewritten multiple times, as discussed in Is caching of boxed Byte objects not required by Java 13 SE spec?

You’ve cited the version use up to Java 7:

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Note that it forgot to mention long.

In Java 8, the specification says:

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

Which applies to literals only.

Since Java 9, the specification says

If the value p being boxed is the result of evaluating a constant expression (§15.28) of type boolean, char, short, int, or long, and the result is true, false, a character in the range '\u0000' and '\u007f' inclusive, or an integer in the range -128 to 127 inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

This now refers to constant expressions, includes long and forgot about byte (has been re‑added in version 14). While this is not insisting on a literal value, a reflective method invocation is not a constant expression, so it doesn’t apply.

Even when we use the old specification’s wording, it’s not clear whether the code implementing the reflective method invocation bears a boxing conversion. The original code stems from a time when boxing conversions did not exist, so it performed an explicit instantiation of wrapper objects and as long as the code contains explicit instantiations, there will be no boxing conversion.

---

In short, the object identity of wrapper instances returned by reflective operations is unspecified.

---

Looking at it from the implementors point of view, the code handling the first reflective invocation is native code, which is much harder to change than Java code. But since JDK 1.3, these native method accessors get replaced by generated bytecode when the number of invocations crosses a threshold. Since repeated invocations are the performance critical ones, it’s important to look at these generated accessors. Since JDK 9, these generated accessors use the equivalent of boxing conversions.

So running the following adapted test code:

import java.lang.reflect.Method;

public class Test
{
    public static boolean testTrue() {
        return true;
    }

    public static void main(String[] args) throws Exception {
        int threshold = Boolean.getBoolean("sun.reflect.noInflation")? 0:
                Integer.getInteger("sun.reflect.inflationThreshold", 15);

        System.out.printf("should use bytecode after %d invocations%n", threshold);

        Method m = Test.class.getMethod("testTrue");

        for(int i = 0; i < threshold + 10; i++) {
            Object trueResult = m.invoke(null);
            System.out.printf("%-2d: %b%n", i, trueResult == Boolean.TRUE);
        }
    }
}

will print under Java 9 and newer:

should use bytecode after 15 invocations
0 : false
1 : false
2 : false
3 : false
4 : false
5 : false
6 : false
7 : false
8 : false
9 : false
10: false
11: false
12: false
13: false
14: false
15: false
16: true
17: true
18: true
19: true
20: true
21: true
22: true
23: true
24: true

Note that you can play around with the JVM options -Dsun.reflect.inflationThreshold=number, to alter the threshold, and -Dsun.reflect.noInflation=true, to let Reflection use bytecode immediately.

invoke will always return a new Object. Any returned primitives are boxed.

...if the [return] value has a primitive type, it is first appropriately wrapped in an object.

Your issue is demonstrating the ambiguity of the term appropriately. i.e. during wrapping, it does not use Boolean.valueOf(boolean).