Java automatic unboxing - is there a compiler warning?

Question

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;
    }
}

South

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

Cocaine

Thanks - I think I will do the same. Even if it doesn't catch the problem it should make debugging the problem easier. – South

There is an issue for separating the boxing from unboxing warnings: bugs.eclipse.org/bugs/show_bug.cgi?id=163065 – Naucratis

Answer 2

Yup. In Eclipse:

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

Yorker

Sorry maybe I should be clearer (I'll modify the question). I want a warning on unboxing but not on boxing. – South

Ah, no Eclipse will not let you distinguish between the two. – Yorker

@Yorker Hopefully this: bugs.eclipse.org/bugs/show_bug.cgi?id=163065 will be implemented. – Naucratis

Answer 3

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?

Delayedaction

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

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

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

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

Answer 4

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.

Chromogenic