Which is better: letting Java do autoboxing or using valueOf()

Question

I am just wondering is there any difference in letting java autobox say an integer:

Integer myInteger = 3; // This will call Integer.valueOf()

or having your code as

Integer myInteger = Integer.valueOf(3);

Is there any micro optimization on this? I know the second one is more explicit, but it is also more unnecessary typing, is there any difference besides this?.

Guideboard

Answer 1

They are equal anyway internally, so use the first variant. Chances are good, that future compiler optimizations may make the first even faster in the future.

Cryptogam

Chances are good, that future compiler optimizations may make the first even faster in the future. That makes no sense, if there are to be any intrinsic, they are to be applied for both. – Falito

Counterexample: They might decide to define constants for the first 5 number, while currently they use an array to store the first 127 (?) instances. The compiler might decide to turn the first into a myInteger = Integer.THREE, while the other still is a method call and array access. – Cryptogam

Again it makes no sense... If they add ANY constants it will make zero difference for the JIT – Falito

Not the JIT does the transformation, but javac! JIT does other nice things. – Cryptogam

The difference is that the code is not executed by javac but the compiled code by the JIT – Falito

bestsss: It is the compiler, that turns e.g. String concatenation to calls to StringBuilder. Simply, because there is no String concatenation defined in bytecode instructions. Also there is no autoboxing defined in bytecode instructions. This is compiler work, not runtime work. The compiler recognizes that there is autoboxing needed to get some working bytecode out of the source. And the compiler can do it in any way he wants, as long as he comforms to the spec. When done, the bytecode doesn't need to know anymore, if there was autoboxing or manual boxing with an explicit call to valueOf. – Cryptogam

@Daniel, you that length to explain how a javac can actually make the program faster...lets see the ICONST_X byte codes get constants defined in some class (say Integer) that alone ensures the code won't run w/ older java; however changing the JIT (in that newer java) will ensure that even older code, not compiled w/ the so-cool new feature, is to run just the same... and that's what would might happen instead, not polluting the code w/ useless constants. I am done w/ the discussion, it's getting just pointless – Falito

There is a reason why old code create with StringBuffers (for speed) is not fast anymore compared to code that could also have been created with String concatenation. Because they reworked Java, and now the former slower, but more readable code, is magically faster! Sorry I could not explain it better so you are able to understand that. – Cryptogam

wow, this never ends. concat has been always faster than StringBuffer/Builder, always. – Falito

@Falito I would disagree with you on that last part. Assuming a and b are Strings, String s = a + b; will be translated by the compiler to String s = new StringBuilder(a).append(b).toString(); In fact, Item 51 of Effective Java is titled "Beware the performance of string cocatenation" for a reason... Quote, "The moral is simple: don't use the string concatenation operator to combine more than a few strings unless perfromance is irrelevant." – Geist

String s = new StringBuilder(a).append(b).toString(); actually it is new StringBuilder(Stingg.valueOf(a))... I never meant the + operator but String.concat, for 2 strings, String.concat() has always been fastest way. (side note, i am very, very well aware how stringBuffer/builder and string are impl. internally, back in the day even we had AsyncStringBuffer that actually copied the strings unlike StringBuffer, which tended to cause some leaks and fragmentation) (edit: unless clear: String.concat is the best for 2 and 2 only string, for more the other methods are better) – Falito

Hey bestsss: I just wanted to give a (possible, but unlikely) was how the JVM, the compiler and the libraries might change in the future in a way that Integer a = 3 is not equal to Integer.valueOf(3) anymore. In my unlikely, but possible example I wanted to give an example, how such a change might look. And I still believe the compiler plays a role here, not just the JIT, which you denied, if I understand you correctly. – Cryptogam

Answer 2

I'd use the first choice. It's the same thing with less code.

Unless I expect that the program would have to run on an older version of JVM. However, in that case this would be far from being the only compatibility issue.

So, the only reason not to use autoboxing is if it's not available.

Cantina

In an older version of the JVM there was no autoboxing anyway, so this wouldn't compile. Starting from 1.5, where autoboxing became available, the variants where the same. – Cryptogam

@Daniel: Yeah, that's the good side. You know if it doesn't work right away, after compilation (or fail). – Cantina

Answer 3

That I know, there really isn't a huge difference in performance see this post here The difference isn't really a difference, but you should use valueOf, because Integer now caches Integer objects between -128 and 127.

Toluol

Why just for server side ops? On the client it is equally performant. – Cryptogam

I just supposed that he/she was doing server side development(web site of web application), java is mostly used for that :) – Toluol

Fixed :) hope it was ok for you. – Cryptogam