Why doesn't Java autoboxing extend to method invocations of methods of the autoboxed types?

Question

I want to convert a primitive to a string, and I tried:

myInt.toString();

This fails with the error:

int cannot be dereferenced

Now, I get that primitives are not reference types (ie, not an Object) and so cannot have methods. However, Java 5 introduced autoboxing and unboxing (a la C#... which I never liked in C#, but that's beside the point). So with autoboxing, I would expect the above to convert myInt to an Integer and then call toString() on that.

Furthermore, I believe C# allows such a call, unless I remember incorrectly. Is this just an unfortunate shortcoming of Java's autoboxing/unboxing specification, or is there a good reason for this?

Answer 1

Java autoboxing/unboxing doesn't go to the extent to allow you to dereference a primitive, so your compiler prevents it. Your compiler still knows myInt as a primitive. There's a paper about this issue at jcp.org.

Autoboxing is mainly useful during assignment or parameter passing -- allowing you to pass a primitive as an object (or vice versa), or assign a primitive to an object (or vice versa).

So unfortunately, you would have to do it like this: (kudos Patrick, I switched to your way)

Integer.toString(myInt);

Answer 2

Ditto on what Justin said, but you should do this instead:

Integer.toString(myInt);

It saves an allocation or two and is more readable.

Answer 3

One other way to do it is to use:

String.valueOf(myInt);

This method is overloaded for every primitive type and Object. This way you don't even have to think about the type you're using. Implementations of the method will call the appropriate method of the given type for you, e.g. Integer.toString(myInt).

See http://java.sun.com/javase/6/docs/api/java/lang/String.html.

Answer 4

seems like a shortcoming of the specification to me

There are more shortcomings and this is a subtle topic. Check this out:

public class methodOverloading{
   public static void hello(Integer x){
      System.out.println("Integer");
   }

   public static void hello(long x){
      System.out.println("long");
   }

   public static void main(String[] args){
      int i = 5;
      hello(i);
   }
}

Here "long" would be printed (haven't checked it myself), because the compiler choses widening over autoboxing. Be careful when using autoboxing or don't use it at all!

Answer 5

The valid syntax closest to your example is

((Integer) myInt).toString();

When the compiler finishes, that's equivalent to

Integer.valueOf(myInt).toString();

However, this doesn't perform as well as the conventional usage, String.valueOf(myInt), because, except in special cases, it creates a new Integer instance, then immediately throws it away, resulting in more unnecessary garbage. (A small range of integers are cached, and access by an array access.) Perhaps language designers wanted to discourage this usage for performance reasons.

Edit: I'd appreciate it if the downvoter(s) would comment about why this is not helpful.

Answer 6

In C#, integers are neither reference types nor do they have to be boxed in order for ToString() to be called. They are considered objects in the Framework (as a ValueType, so they have value semantics), however. In the CLR, methods on primitives are called by "indirectly" loading them onto the stack (ldind).

Answer 7

As everyone has pointed out, autoboxing lets you simplify some code, but you cannot pretend that primitives are complex types.

Also interesting: "autoboxing is a compiler-level hack" in Java. Autoboxing is basically a strange kludge added onto Java. Check out this post for more details about how strange it is.

Answer 8

It would be helpful if Java defined certain static methods to operate on primitive types and built into the compiler some syntactic sugar so that

5.asInteger

would be equivalent to

some.magic.stuff.Integer.asInteger(5);

I don't think such a feature would cause incompatibility with any code that compiles under the current rules, and it would help reduce syntactic clutter in many cases. If Java were to autobox primitives that were dereferenced, people might assume that it was mapping the dereferencing syntax to static method calls (which is effectively what happens in .NET), and thus that operations written in that form were no more costly than would be the equivalent static method invocations. Adding a new language feature that would encourage people to write bad code (e.g. auto-boxing dereferenced primitives) doesn't seem like a good idea, though allowing dereferencing-style methods might be.