Why auto-boxing marked as a warning?

Question

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?

Impetuosity

My out-of-the-box eclipse doesn't show warnings for auto-boxing and un-boxing. What type/version of eclipse are you using? – Schach

You can enable it (and other different warnings) in Project Properties -> Java Compiler ->Errors/Warnings -> Potential Programming Problems. – Impetuosity

See: bugs.eclipse.org/bugs/show_bug.cgi?id=163065 It's a feature request to separate boxing from unboxing. – Accord

Answer 1

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.

Caucasia

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) – Impetuosity

@Impetuosity 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. – Caucasia

There is a bug related to separating these warnings: bugs.eclipse.org/bugs/show_bug.cgi?id=163065 – Accord

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 – Imponderable

@Caucasia You should use Integer I = Integer.valueOf(i) so that new instances aren't created for small values (see javadoc) – Vertex

@Caucasia "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" – Ostend

Answer 2

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/

Acquit

Answer 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)

Rosaleerosaleen

That's the expected behaviour for overloaded functions and not a bug. – Micronesian

@KarlRichter I am quite sure that this answer means "... can contribute to the developer creating a bug..." (which I totally agree with). – Acquit

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. – Rosaleerosaleen