Jul 142004

There has been a lot of talk lately about the JDK 5 auto-boxing issues and how everyone thinks it should work or whether or not it should even exist. The main thread I found and posted to was over here.

Just wanted to discuss this in some more detail. Auto-boxing is 100% code-generation. It is an auto-conversion between objects and primitives. Here’s what that means. If you code this:

Java generates code that actually does this:

Okay, what does this mean? It means that the int passed into the valueOf method is converted to an Integer AND if it has already been converted, Java can choose to return the previously created Integer or a new Integer. This allows Java to cache the instances of Integer so that the memory footprint is smaller. This means that two separate calls to this method with the same int MIGHT return the same object. Here’s an example:

So, what does it print out? Totally unknown! Why? Because any JVM can implement this method anyway it sees fit. The fact that Sun’s JVM caches values from -127 to 127 is completely arbitrary. The contract of this method states:

Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values.

It doesn’t tell us when it caches or how it caches, just that it can cache. So, why not just not cache and make everyone’s lives easy? Because doing that would mean that every autobox operation would create a new object. This might seem relatively low concern for people who are simply putting things into Maps, but for those people that are fetching values from Maps and doing math with those values and putting the result back into the Maps, this would slow the application down.

Okay, now that the way things works has been covered, here’s what I think about autoboxing use. As I said on the thread over at TheServerSide: if you can use primitives do, if you can’t don’t. Simple huh? Well, it makes good sense because for performance reasons, you still do not want to incur the overhead of calling valueOf if all you are doing is counting. That just wouldn’t make any sense. Likewise, if you are putting values into a Map and the key is an index or primary key from a database, doesn’t make sense to use an int.

What I think about the use of valueOf? Well, I think it’s fine. I know better than to ever compare Objects using the == operator and everyone else that uses Java should know this as well. For that matter, you should know whether or not you have autoboxed something and which equality operation is correct (== or .equals()). I think that my rule from above helps to clarify this issue. If you are using primitives, you are probably doing math of some sort. This usually entails equality operations or something similar (greater-than, less-than). In these situations, you can safely use ==. However, if you can’t use primitives, than you shouldn’t right? In these cases you are mostly passing int into methods that take either Object, Number of Integer. Therefore, you shouldn’t be doing an comparisons on these values.

I can already see the responses… What if I am summing values in a Map and want to break when the sum is a certain value? Okay, if you can use primitives do so:

If you can’t, don’t.

To me this makes sense. Java’s de-autobox gets us back to a state where we can use primitives. All the operations we do on that primitive can be done on primitives, so we go ahead and do it. Then we get back to the case where we can’t use a primitive because the method requires an Integer. Therefore, we allow the Java compiler to autobox the value for us.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">



This site uses Akismet to reduce spam. Learn how your comment data is processed.