• Post Reply Bookmark Topic Watch Topic
  • New Topic

Ways to box an int  RSS feed

 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a difference in boxing ints with these two methods?

Integer Ix = new Integer(x);
Integer Ix = Integer.valueOf(x);

Which is preferable? Thanks.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The second one is better, as it uses a cache of Integer objects for certain values; -128 to 127 are guaranteed, and it's possible to extend the upper bound of this range through a system property.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Spoor wrote:The second one is better, as it uses a cache of Integer objects for certain values; -128 to 127 are guaranteed, and it's possible to extend the upper bound of this range through a system property.


Thanks, Rob!
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can ofcourse let the compiler do the boxing automatically, by writing something like this:

The compiler changes this automatically to a call to Integer.valueOf(), so the line above works exactly the same as:

I'd make use of autoboxing and not do the boxing manually, because it allows you to keep your code shorter and more clear - and the compiler will automatically choose the most efficient method to box the value for you.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:You can ofcourse let the compiler do the boxing automatically


I could, but then I wouldn't be learning very much!

I do like autoboxing, but autounboxing is problematic as the value could be NULL. Therefore I try to avoid autounboxing if possible, just to make the code explicit about what is happening (easier to find bugs that way). Is there some directive or statement that can disable autounboxing? I do have Eclipse set to warn on autounboxing.

Thanks.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to make sure that you don't allow nulls (not "NULL") into your code in the first place. Make sure every Integer (or other wrapper) field is initialised in the constructor, and not to null. It is not so bad with local variables or parameters; the compiler will not permit uninitialised local variables, and any boxed ints must have a value, so the only way you can get a null Integer is like thisThe answer to that is to get yourself a method to check for nulls.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:You need to make sure that you don't allow nulls (not "NULL") into your code in the first place.


I agree with the diligence, but I still insist on being defensive. I would rather add another line of code and not have the user get an NPE due to some corner-case which I missed. Bugs happen!
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Dotan, I also have setup Eclipse to warn about auto-boxing and auto-unboxing. Not only does it help me identify NPEs faster, it also helps me prevent boxing when it's not necessary (because of a typo). Especially in one project there are some classes that have methods getLongValue and getlongValue, the first one returning a Long and the second a long. It's quite easy in that case to use getLongValue and assign the return value to a long, thereby unnecessarily first boxing and then unboxing.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I showed you is defensive programming. If the user is mistakenly passing a null, it is better to throw an Exception there and then when its cause is easily identifiable. If you don't throw the Exception there, you are more likely to suffer the Exception later on when its cause is difficult to pinpoint.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:What I showed you is defensive programming. If the user is mistakenly passing a null, it is better to throw an Exception there and then when its cause is easily identifiable. If you don't throw the Exception there, you are more likely to suffer the Exception later on when its cause is difficult to pinpoint.


I understand that it is sometimes advantageous to determine _why_ a null was passed. But not always, sometimes I want the code to recover gracefully and keep working. In this case I would rather that the value be considered as a safe value with a sensible outcome than just letting the exception occur then logging and ignoring it.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Agree there are places where null is a valid value, for example at the ends of a Tree (the leaf nodes always have nulls in), or retrieving my middle name from a database with JDBC or similar. Since I haven't got a middle name, that will return null. There you would need == null checks, and special handling for nulls.
But you have implied that you don't want nulls for your Integers, so you are better off preventing them getting into your method in the first place. Of course, the stack trace for that Exception will give you a good hint.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
. . . and I have shown how you can prevent most of the nulls, earlier. Remember, the longer you leave a null wandering round your application, the more difficult it is to find out why it is there.
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Remember, the longer you leave a null wandering round your application, the more difficult it is to find out why it is there.


That is good advice! I will be sure to check the values for nulls both when receiving the data (at the start of the function) and before sending it on it's way (return).

Thank you!
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are sure you aren't letting nulls into your method, you should be able to work out whether there is any risk of its returning null.

Another thing; it is very easy to write things like x = y; If y was null, now your nulls are breeding and multiplying Like rabbits!
 
Dotan Cohen
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:If you are sure you aren't letting nulls into your method, you should be able to work out whether there is any risk of its returning null.

Another thing; it is very easy to write things like x = y; If y was null, now your nulls are breeding and multiplying Like rabbits!


That's exactly what I need to hear, I have a pregnant Siberian Gerbil loose in the house... And if I don't find her soon I'll have eight Siberian Gerbils loose in the house. I know exactly how rodents breed!
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Swap her for a guinea-pig. They only have one at a time.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!