11

I am a big fan of auto-boxing in Java as it saves a lot of ugly boiler plate code. However I have found auto-unboxing to be confusing in some circumstances where the Number object may be null. Is there any way to detect where auto-unboxing is occurring in a codebase with a javac warning? Any other solution to detect occurrences of unboxing only (such as FindBugs or Eclipse-specific compiler warning) would be appreciated as I cannot find any.

To clarify I do not want any warnings to be generated on boxing - only unboxing.

Here is a simple example of some code that can cause confusing NullPointerExceptions: 

class Test {
    private Integer value;

    public int getValue() {
        return value;
    }
}
Russ Hayward
  • 5,617
  • 2
  • 25
  • 30

4 Answers4

5

Yup. In Eclipse:

Preferences->Java->Compiler->Errors/Warnings->Potential Programming Problems->Boxing and unboxing conversions

skaffman
  • 398,947
  • 96
  • 818
  • 769
2

Unfortunately there is not. This is one of the issues with auto unboxing numbers. You can

  • Initialize it to a default value, such as private Integer value = 0
  • Check for a null return value != null ? value : 0

Personally I prefer the first method. In general I would think you wouldn't have too many cases where you should have a null number.

Also, why are you using a big Integer to store the value. If you're only returning a little int, why not store it that way?

Jeff Storey
  • 56,312
  • 72
  • 233
  • 406
  • Sometimes API/interface operability requires to return int while long/BigInteger would be available. Oh how I'd love to have a `List` with `Long.MAX_VALUE` entries but alas I just can't do that. – Esko Jan 09 '10 at 14:26
  • You can have a `List` that big; it just can't tell you that it's that big. In `LinkedList`, for example, it maintains a field `size` of type `int`, but it never checks to make sure that the size didn't overflow. There are some operations that will fail, though, based on making sure that the current index is *less than* the size, which wouldn't hold if the `size` field have overflowed to a negative value. – seh Jan 09 '10 at 14:40
  • I can't use a `List` with Long.MAX_VALUE items as a drop-in replacement in my code though and that's where it matters. I very well know the semantics of `AbstractList` and the like, however as long as the interface itself says `int`, I'm bound to it. – Esko Jan 09 '10 at 15:26
  • I agree that a primitive type is always best if possible for this sort of thing. The sample code is just an example of what can happen. I have only really encountered this problem when picking up code from other developers who are new to Java and tend to overuse wrapper classes. – Russ Hayward Jan 10 '10 at 11:19
1

Eclipse will let you syntax-color boxing and unboxing operations (but not one or the other). I have them set to bright red: if either happens, it means that I've been sloppy in matching parameters and arguments.

kdgregory
  • 38,754
  • 10
  • 77
  • 102
  • Thanks - I think I will do the same. Even if it doesn't catch the problem it should make debugging the problem easier. – Russ Hayward Jan 10 '10 at 11:20
  • 2
    There is an issue for separating the boxing from unboxing warnings: https://bugs.eclipse.org/bugs/show_bug.cgi?id=163065 – Kyle Sep 06 '13 at 03:19
1

I doubt that this will be a warning case. This is one of the quirks of auto-boxing.

Joshua Bloch addresses this in his book "Effective Java". Basically, the compiler is trying to do more for you that what is expected. In other words, this type of issue is more commonly related to usage and as a result, it is difficult to "spot the error" as the error is, semantically speaking, simply not there.

gpampara
  • 11,989
  • 3
  • 27
  • 26