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

Question

To my understanding following code should print "true", but when I run it it prints "false".

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

    public static void main(String[] args) throws Exception {
        Object trueResult = Test.class.getMethod("testTrue").invoke(null);
        System.out.println(trueResult == Boolean.TRUE);
    }
}

According to JLS §5.1.7. Boxing Conversion:

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

However in case of method called via reflection boxed value is always created via new PrimitiveWrapper().

Please help me understand this.

Dolora

Strictly speaking, Boolean.TRUEis not the "result of a boxing conversion". – Auroora

Ok, there is no auto-boxing. This part of the JLS is about auto-boxing – Eyelet

Well, "in case of a reflection" is not covered by that part of the JLS you're quoting. That part is a continuity about variable conversion when you have a value of a type that you assign to another type using the language normally. Reflection is not a part of that. – Eyelet

The JLS mandates boxing conversions for a conversion from boolean to Boolean. In the case of reflection, the conversion is however from boolean to Object. The code behind Method.invoke() may therefore call new Boolean(b) to convert from boolean to Object without violating the letters of the JLS. – Aulic

Answer 1

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).

Lawford

Just to add a suggestion of the reason why it might be so: the reflection API was added in 1.1; Boolean.valueOf was added in 1.4. Perhaps the pre-valueOf behavior was retained for backwards compatibility. – Saith

@AndyTurner You are on the right track, there was no valueOf method for Boolean prior to 1.4 (for the other types it took even longer) and even then, there was no formal definition of boxing conversions, which where only introduced the next version. But I don’t think that the reason for keeping the behavior ever was backward compatibility but rather “No-one took the time to change it”. But since JDK 9, it has changed; you just need to perform more than one invocation to encounter the changed behavior, depending on the JRE configuration. – Majoriemajority

Answer 2

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.

---

Update: starting with JDK 18, the values are always boxed using valueOf(…)

Majoriemajority

Answer 3

1.

The specific

in case of method called via reflection

is not covered by that part of the JLS you're quoting. That part you're quoting is about type conversion when you have a value of a type that you pass as another type. Here you're thinking of converting boolean to Boolean.

But type conversion means doing something like that:

Boolean b = true;

or

boolean b = true;
Boolean b2 = b;

Reflection is not a mechanism that applies type conversion.

When, by necessity, a reflective method call wraps a boolean return value into a Boolean object, it is not involved in the part of the JLS you quoted.

This explains why the JLS is not being violated here.

2.

As to why the reflection isn't choosing to be consistent with this behavior anyway:

That is because in older versions of Java, reflection existed before generics. And generics are the reason why autoboxing suddenly became convenient, and autoboxing is the reason why it seemed smart to not duplicate the "common" values of wrapped primitives.

All of this was defined after reflection already existed for a while, and was already behaving in a specific way. That means that there was already existing Java code that was using reflection, and most likely some existing code that was incorrectly relying on the existing behavior. Changing the existing behavior would have broken existing code, which was therefore avoided.

Eyelet

"most likely some existing code that was incorrectly relying on the existing behavior" Wouldn't that have to be incredibly specific? The only code I can think of that would satisfy that statement would be myReturn.booleanValue() && myReturn != Return.TRUE, which is something that no one in their right mind would ever write. I'm not saying you're right or wrong, but if you are right then they've intentionally made every Java user's code minutely worse for years for the sake of a few idiots relying on implementation details. – Olinger

@Olinger Meh, I never worked for Sun nor did I work on an official Java release. But they tend to take preserving backwards compatibility seriously. The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost. This is nowhere near a noticeable cost. – Eyelet

"The only reason why they would accept deriving for it, is if it is unavoidable, or not doing so has a great cost" The introduction of var was avoidable, and not including would not have been a great cost. They've relaxed their view on backwards compatibility in recent years. It was becoming a detriment to the language. – Olinger

@Olinger The Introduction of var was the work of Oracle. There was quite a change. Not saying it's for the better nor worse, but the policy just isn't the same at all. – Eyelet

Yeah and Oracle acquired Java almost a decade ago. Why do you think Sun's policies are relevant? – Olinger

@Olinger I think they are relevant because they covered auto-inbox, which is the subject at the origin of the question here. – Eyelet

@Olinger in most cases, the reason why something doesn’t get changed is a) no-one opened an RFE for it or b) no-one had the time to do it (yet). You wouldn’t believe, how little resources the JDK development has, compared to the size of this project. In fact, the behavior of Reflection has already changed in that regard but you won’t notice on the first invocation (and the question’s test does only one). – Majoriemajority

Answer 4

As you can see in java.lang.reflect.Method class, the invoke method has a signature as following:

 public Object invoke(Object obj, Object... args) { ... }

which returns an object as result.

Furthermore, Boolean.TRUE is defined as:

public static final Boolean TRUE = new Boolean(true);

which is a boxed object of true value.

By evaluating trueResult == Boolean.TRUE in your code, you are checking that whether the reference of trueResult and Boolean.TRUE are equal or not. Because == evaluates equality of values and in case of references, it means that are two references pointed to one Object in memory?

It is obvious that these two objects are not the same (they are two separate objects and instantiated in different parts of memory), so the result of trueResult == Boolean.TRUE is false.

Stiffler

You've missed the point of the question. Let me rephrase it for you, and hopefully you'll see why your answer doesn't answer the question: Why does calling the method via reflection autobox the return by using Boolean's constructor (i.e. creates a new object) while calling the method normally autoboxes using Boolean.valueOf (i.e. returns Boolean.TRUE) – Olinger