But it turns a whole class of bugs from a compile-time error to a runtime-error, and is generally a good way to introduce hard-to-debug performance problems.
Consider this misguided code:
Integer i = new Integer(2);
Integer j = new Integer(2);
assertTrue(i >= j); // success
assertTrue(i <= j); // success
assertTrue(i == j); // failure!
In this case, auto-boxing gets invoked for the >= and the <=, and they are compared as ints, since there is no definition for >= with regard to objects. But not for ==, since that operation is defined as pointer-comparison between the objects.
These types of bugs were hard enough to track down without auto-boxing. Any possible benefit auto-boxing brought in coding-time optimizations are more than lost in debug-time problems. |
java.net RSS Feeds
