What are the strategies for catching unboxing and autoboxing issues at compile time?

Question

I'm editing this question to differentiate it from this one, and to remove the dreaded "why?"

If I have a java method that returns the java object Integer, the java compiler allow me to assign that to a primitive int. This seems to be asking for runtime trouble. ie. what if Integer is null?

public class SomeClass {
    private Integer someIntegerObject;

    public Integer getSomeIntegerObject() {
        return this.someIntegerObject;
    }
}

SomeClass someClass = new SomeClass();
//much later...
int someIntegerPrimative = someClass.someIntegerObject();

This will blow up at runtime if someIntegerObject was set to null at all, but it seems like something that could easily be caught at compile time.

This functionality is called "unboxing" and its opposite is "auto-boxing". It is intended to save the developer time and readability from unboxing each of these manually.

The question is: what are the best strategies for catching potential issues here at compile-time?

https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html — pvg, May 20 '16 at 16:08
The answer to your "what if" is that you get an exception. Auto unboxing is nothing but a shorthand to make your code clearer to the reader. — Philip Couling, May 20 '16 at 16:08
Plus one for discovering what I think is one of the major flaws in Java. Wait until you discover the pre-caching of -128 to +127. The blow-up you get if you attempt to convert a null to an `int` is a NullPointerException which is an *unchecked* exception to make matters even worse. With a sign of relief, I'm back to C++. — Bathsheba, May 20 '16 at 16:10
Possible duplicate of [Why do we use autoboxing and unboxing in Java?](http://stackoverflow.com/questions/27647407/why-do-we-use-autoboxing-and-unboxing-in-java) — Petter Nordlander, May 20 '16 at 16:12
@Bathsheba interesting how you define a major flaw. How is this worse than using the long hand `Integer.intValue()` — Philip Couling, May 20 '16 at 16:12
@Bathsheba I agree that `NullPointerExceptions` are a major flaw in general. But if you're going to say "back to c++" then I will leave you with the words `segmentation fault` and be done with it. — Philip Couling, May 20 '16 at 16:16
How could you? Now we have std::unique_ptr and std::shared_ptr ;-) — Bathsheba, May 20 '16 at 16:16
Easily. I still have to debug code which has C style pointers through it. — Philip Couling, May 20 '16 at 16:17
And as my parting remark, you must admit that type erasure was a really bad idea ! — Bathsheba, May 20 '16 at 16:19
for "why" questions, read: http://meta.stackoverflow.com/q/323334/217324 — путин некультурная свинья, May 20 '16 at 16:23
@NathanHughes- I've edited the question to remove the "why", putting the focus on concrete solutions for catching these issues at compile-time. — Daniel Patrick, May 20 '16 at 18:02

score 6 · Accepted Answer · edited May 23 '17 at 11:58

The JRE / Compiler does something called Auto Unboxing - which is designed to save developer time when it comes to activities like this.

Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes. For example, converting an int to an Integer, a double to a Double, and so on. If the conversion goes the other way, this is called unboxing.

https://docs.oracle.com/javase/tutorial/java/data/autoboxing.html

Edit: you might want to read this re your point on null objects - looks like a runtime error NullPointerException will be thrown, but you can setup most IDE's to warn about auto unboxing at compile time to help you either:

a) Make sure you have the right exception handling or;

b) Make sure you are not relying on the behaviour at all (always calling the method to get the primitive value)

I've edited the question to remove the "why?" and put the focus on compile-time solutions. Since your answer offers those, I will choose this as the solution. — Daniel Patrick, May 20 '16 at 18:03

score 3 · Answer 2 · answered May 20 '16 at 16:16

The concept your talking about is Auto-unboxing. The value of a type wrapper (here Integer) is automatically extracted whenever it is needed. Basically auto-unboxing removes the tedium of manually boxing and unboxing values. It is mostly important to Generics, which operate only on objects. This feature makes working with Collections Framework much easier. And we can always catch a NullPointerException. Java provides pretty good exceptional handling mechanism. Let's use it even if tiniest possibility of exceptions exist.

What are the strategies for catching unboxing and autoboxing issues at compile time?

2 Answers2