Why does not Java autoboxing extend to calls of methods of methods of autobox types?

Question

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

myInt.toString(); 

Error with error:

 int cannot be dereferenced 

Now I get that primitives are not reference types (i.e. not Object) and therefore cannot have methods. However, Java 5 introduced autoboxing and unboxing (a la C # ..., which I never liked in C #, but it’s not). Thus, using autoboxing, I would expect the above to convert myInt to Integer, and then call toString ().

In addition, I believe that C # allows such a call, if I do not remember correctly. Is this just an unfortunate flaw in the Java autoboxing / unpacking specification, or is there a good reason for this?

Answer 1

Java autoboxing / unboxing does not reach the point where you can dereference a primitive, so your compiler prevents it. Your compiler still knows myInt as a primitive. There is an article about this issue on jcp.org .

Autoboxing is mostly useful when passing or passing parameters - it allows you to pass a primitive as an object (or vice versa) or assign a primitive to an object (or vice versa).

So, unfortunately, you will need to do it like this: (Kudos Patrick, I switched to your path)

 Integer.toString(myInt); 

Answer 2

Same as Justin said, but you should do this instead:

 Integer.toString(myInt); 

It keeps highlighting or two or more readable.

Answer 3

Another way to do this is to use:

 String.valueOf(myInt); 

This method is overloaded for each primitive type and Object . That way, you don’t even have to think about the type you are using. Method implementations will call a suitable method of this type for you, for example. Integer.toString(myInt) .

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

Answer 4

seems like a lack of specification to me

There are more flaws, 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" will be printed (he did not check it himself), because the compiler extends the capabilities of autoboxing. Be careful when using autoboxing or do not use it at all!

Answer 5

The valid syntax closest to your example is

 ((Integer) myInt).toString(); 

When the compiler ends, it is equivalent

 Integer.valueOf(myInt).toString(); 

However, this does not work the same as normal use, String.valueOf(myInt) , because, except in special cases, it creates a new Integer instance and then immediately discards it, which leads to unnecessary garbage. (A small range of integers is cached and access is via array access.) Perhaps the language developers wanted to refuse this use for performance reasons.

Edit: I would appreciate if the downvoter would comment on why this does not help.

Answer 6

In C #, integers are not reference types, and they should not be boxed to call ToString (). However, they are considered objects in the Framework (like ValueType, therefore, they have semantics of values). In the CLR, primitive methods are called "indirectly", loading them onto the stack (ldind).

Answer 7

As everyone notes, autoupdate allows you to simplify some code, but you can't pretend that primitives are complex types.

Also interesting: "autoboxing is a compiler level hack" in Java. Autoboxing is essentially a weird kladge added in Java. this post for more details on how weird.

Answer 8

It would be useful if Java defines some static methods for working with primitive types and embeds syntactic sugar in the compiler so that

 5.asInteger 

will be equivalent

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

I do not think that such a function can lead to incompatibility with any code that compiles in accordance with the current rules, and in many cases this will help reduce syntax clutter. If Java belonged to autobox primitives that were dereferenced, people could assume that they mapped the dereferencing syntax to calls to static methods (which actually happens in .NET), and therefore operations written in this form were no more expensive than equivalent ones calls to the static method. Adding a new language feature that encourages people to write bad code (like auto-box-dereferenced primitives) doesn't seem like a good idea, although markup methods can be used.