views:

362

answers:

4

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;
    }
}
+2  A: 

Yup. In Eclipse:

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

skaffman
Sorry maybe I should be clearer (I'll modify the question). I want a warning on unboxing but not on boxing.
Russ Hayward
Ah, no Eclipse will not let you distinguish between the two.
skaffman
+1  A: 

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
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
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
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
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
+1  A: 

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
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
+1  A: 

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