21

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

Marc W
  • 19,083
  • 4
  • 59
  • 71
Oscar Gomez
  • 18,436
  • 13
  • 85
  • 118

3 Answers3

20

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.

Daniel
  • 27,718
  • 20
  • 89
  • 133
  • 2
    *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. – bestsss Mar 09 '11 at 23:09
  • 6
    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. – Daniel Mar 09 '11 at 23:12
  • Again it makes no sense... If they add ANY constants it will make zero difference for the JIT – bestsss Mar 09 '11 at 23:14
  • 1
    Not the JIT does the transformation, but javac! JIT does other nice things. – Daniel Mar 09 '11 at 23:15
  • The difference is that the code is not executed by javac but the compiled code by the JIT – bestsss Mar 09 '11 at 23:17
  • 1
    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. – Daniel Mar 09 '11 at 23:22
  • @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 – bestsss Mar 09 '11 at 23:35
  • 1
    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. – Daniel Mar 09 '11 at 23:41
  • wow, this never ends. concat has been always faster than StringBuffer/Builder, always. – bestsss Mar 10 '11 at 17:05
  • 2
    @bestsss 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."` – corsiKa Mar 10 '11 at 21:57
  • `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) – bestsss Mar 10 '11 at 21:59
  • 1
    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. – Daniel Mar 11 '11 at 10:26
4

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.

Goran Jovic
  • 9,418
  • 3
  • 43
  • 75
  • 1
    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. – Daniel Mar 09 '11 at 22:57
  • @Daniel: Yeah, that's the good side. You know if it doesn't work right away, after compilation (or fail). – Goran Jovic Mar 09 '11 at 23:03
1

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.

Community
  • 1
  • 1
7dr3am7
  • 755
  • 1
  • 8
  • 21