Does autoboxing call valueOf()?

I'm trying to determine whether the following statements are guaranteed to be true:

((Boolean)true) == Boolean.TRUE
((Boolean)true) == Boolean.valueOf(true)
((Integer)1) == Integer.valueOf(1)

I've always assumed that autoboxing was equivalent to calling valueOf() on the corresponding type. Every discussion that I've seen on the topic seems to support my assumption. But all I could find in the JLS was the following (§5.1.7):

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

That describes behavior identical similar* to that of valueOf(). But there doesn't seem to be any guarantee that valueOf() is actually invoked, meaning there could theoretically be an implementation that keeps a separate, dedicated cache for autoboxed values. In such a case, there might not be identity equality between cached autoboxed values and regular cached boxed values.

Oracle's autoboxing tutorial states matter-of-factly that li.add(i) is compiled to li.add(Integer.valueOf(i)), where i is an int. But I don't know whether the tutorial should be considered an authoritative source.

---

_{*It's a slightly weaker guarantee than valueOf(), as it only refers to literal values.}

I first tought your question was a dupe of https://stackoverflow.com/questions/408661/what-code-does-the-compiler-generate-for-autoboxing

However, after your comment on @ElliottFrisch I realized it was different :

> I know the compiler behaves that way. I'm trying to figure out whether > that behavior is guaranteed.

For other readers, assume that "behaves that way" means using valueOf.

Remember that there are multiples compilers for Java. To be "legal" they must follow the contract given in the JLS. Therefore, as long as all the rules here are respected, there is no guarantee of how autoboxing is internally implemented.

But I don't see any reason to not use valueOf, specially that it uses the cached values and is the recommended way as per this article by Joseph D. Darcy.

Until the language specification mentions it, it is not guaranteed that autoboxing is equivalent to a call to the static valueOf methods. It is an implementation aspect, not part of the boxing conversion specification. An implementation is theoretically free to use another mechanism as long as it conforms to the rule you mentioned from the JLS.

In practice, there are many Sun JDK bug reports (e.g. JDK-4990346 and JDK-6628737) that clearly imply that when autoboxing was introduced in Java 5, the intention was having the compiler to rely on valueOf as stated in JDK-6628737:

>The static factory methods Integer.valueOf(int), Long.valueOf(long), etc. were introduced in JDK 5 for javac to implement the caching behavior required by the autoboxing specification.

But that's only for javac, not necessarily all compilers.

Autoboxing is absolutely implemented using valueOf() ...in the OpenJDK. If that's your implementation, read on... if not, skip to below.

((Boolean)true) == Boolean.TRUE
((Boolean)true) == Boolean.valueOf(true)

Java documentation states that Boolean.valueOf() always returns Boolean.TRUE or Boolean.FALSE, therefore your reference comparisons in these cases will succeed.

((Integer)1) == Integer.valueOf(1)

For this particular example, under the OpenJDK implementation with default settings, it will probably work by virtue of the fact that you picked a value < 128 which is cached at startup (although this can be overridden as a commandline arg). It may also work for larger values if it's frequently used enough to be cached. Unless you're working under "safe" assumptions about the Integer cache, don't expect the reference comparison to be an equality.

Long, Short, Character and Byte incidentally implement this caching too, but unlike Integer, it's not tunable. Byte will always work if you're comparing autobox/valueOf() references since obviously, you can't go out of range. Float and Double will unsurprisingly always create a new instance.

---

Now, in purely generic terms? See this section of the JLS - you MUST be given equal references for boolean and any int or char within the -128 to 127 range. There are no guarantees for anything else.

> Oracle's autoboxing tutorial states matter-of-factly that li.add(i) is compiled to li.add(Integer.valueOf(i)), where i is an int. But I don't know whether the tutorial should be considered an authoritative source.

I'm running Oracle Java 1.7.0_72 it looks like it does use valueOf. Below is some code and the bytecode for it. The bytecode shows it is using valueOf.

public class AutoBoxing {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Integer x = 5;
        int i = x;
        System.out.println(x.toString());
    }
    
}





Compiled from "AutoBoxing.java"
public class testing.AutoBoxing {
  public testing.AutoBoxing();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: iconst_5
       1: invokestatic  #2                  // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
       4: astore_1
       5: aload_1
       6: invokevirtual #3                  // Method java/lang/Integer.intValue:()I
       9: istore_2
      10: getstatic     #4                  // Field java/lang/System.out:Ljava/io/PrintStream;
      13: aload_1
      14: invokevirtual #5                  // Method java/lang/Integer.toString:()Ljava/lang/String;
      17: invokevirtual #6                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      20: return

But I do not know what Open JDK uses. Will try it out.