15

I understand that auto un-boxing should be done with care because the reference that is being un-boxed can be null. Why is auto-boxing marked as warning as well? Are there some pitfalls I am missing here?

Artium
  • 5,147
  • 8
  • 39
  • 60
  • My out-of-the-box eclipse doesn't show warnings for auto-boxing and un-boxing. What type/version of eclipse are you using? – LanguagesNamedAfterCofee Nov 23 '11 at 20:27
  • 2
    You can enable it (and other different warnings) in Project Properties -> Java Compiler ->Errors/Warnings -> Potential Programming Problems. – Artium Nov 23 '11 at 20:32
  • See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=163065 It's a feature request to separate boxing from unboxing. – Kyle Sep 06 '13 at 03:17

3 Answers3

8

I was going to disable this Eclipse warning but the following article made me consider not to. I'm still not completely sure but it looks to me like those might be good reasons to just avoid autoboxing.

https://effective-java.com/2010/05/the-advantages-and-traps-of-autoboxing/

keiki
  • 3,260
  • 3
  • 30
  • 38
SantiBailors
  • 1,596
  • 3
  • 21
  • 44
7

If you don't expect performance issues (in terms of micro-optimization) you can safely disable this warning. It is just an indication in case you're not aware that auto-boxing happends here. In business-logic code where you have I/O overhead (due to DB transactions or disc access) auto-boxing hardly becomes a performance issue.

stacker
  • 68,052
  • 28
  • 140
  • 210
  • 1
    In eclipse, it is not possible to turn of only boxing warnings without turning off un-boxing warnings as well. Is it somethings you would suggest turning off (both off them)? I am doing a university project and the tutor wants zero warnings on maximum warning level.(selectively ignoring warnings is allowed) – Artium Nov 23 '11 at 20:35
  • @Artium In your case you could use explicit conversions so that the operation is visible from `int i = Integer.intValue()` and `Integer I = new Integer(i)`. After that the compiler won't complain. – stacker Nov 24 '11 at 08:11
  • 1
    There is a bug related to separating these warnings: https://bugs.eclipse.org/bugs/show_bug.cgi?id=163065 – Kyle Sep 06 '13 at 03:16
  • 2
    Auto-boxing is never an issue, but auto-unboxing provides space for NullPointerException which is not that easy to notice, especially when you hit it for the first time. For example, your method receives an "Integer value" and then calls another method that expects 'int value', so your call anotherMethod(value) may throw a NullPointerException if you receive null argument – xorcus Dec 18 '13 at 12:12
  • 4
    @stacker You should use `Integer I = Integer.valueOf(i)` so that new instances aren't created for small values (see [javadoc](http://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#valueOf(int))) – Max Nanasy Mar 18 '14 at 00:41
  • @stacker "Auto-boxing is never an issue" - I disagree: There are some pitfalls with comparisons. Consider weakening your statement to "Auto-boxing is normally not an issue" – Qw3ry Jul 08 '19 at 11:17
3

Autoboxing can contribute to the developer creating a bug related to the "remove" method of Collections, though this is probably a pretty obscure bug.

I've encountered this bug when I used a random number generator to select the index of an item to remove from an ArrayList. The generator returned a long primitive, which I accidentally tried to use as the parameter for List.remove(int index). The compiler converted the long to a Long and used it in List.remove(Object o), which gave totally different behavior. Luckily, an assert statement caught the error quickly.

According to this discussion of this issue with "remove", someone else ran into a similar problem where their int unexpectedly acted like an Integer, though I don't understand how that happened. Why aren't Java Collections remove methods generic? (see comment by ScArcher2)

adam.r
  • 247
  • 2
  • 12
  • That's the expected behaviour for overloaded functions and not a bug. – Kalle Richter Mar 10 '15 at 18:31
  • 1
    @KarlRichter I am quite sure that this answer means "... can contribute to _the developer creating_ a bug..." (which I totally agree with). – SantiBailors Apr 04 '18 at 08:18
  • Yes, that is what I meant. Thanks for suggesting the language to clarify the issue. I had been working on the understanding that "Warnings" were specifically meant to warn developers that they may have created a bug. – adam.r Apr 04 '18 at 20:33