Thread: How can I Autoboxing?

Sometimes boxing is necessary (and quite helpful). For example, you can't use primitives as generic parameters.

ArrayList<Integer> myList = new ArrayList<Integer>(); // must use the Integer wrapper class in generics
myList.add(1); // 1 is of type int, not Integer. However, it gets auto-boxed so this is perfectly legal

The equivalent code without using auto-boxing (well, technically this is still "boxing", or wrapping, but it's not automatic)

ArrayList<Integer> myList = new ArrayList<Integer>();
myList.add(new Integer(1));

I just gave a perfectly clear example of why Auto-boxing is useful

From a code maintainability standpoint, the first piece of code I have is much easier to read. In industry, code maintainability is almost always a top priority (depending on the situation, performance sometimes dominates over maintainability, or laziness/time constraints can dominate too).

Also, whenever you use math operations with Integer/wrapper classes, the values are un-boxed to perform the operations (of course, this issue could be circumvented by having overloaded operators, but this is how Java decided to implement it).

So, this prevents you from having to do something like this:

Integer a = new Integer(5);
Integer b = new Integer(3);
 
// perform (a + b) * (a - b)
// these methods actually don't exist in the Integer class, but hopefully you can tell what it is they are doing
// this is actually very similar to how you would have to do this if you were to use BigInteger, but that's a whole other can of worms
Integer c = a.add(b).multiply(a.subtract(b));

If you were someone looking at this, wouldn't you prefer (a + b) * (a - b)? It would definitely be much easier to read, and it would also be much easier to write in the first place (you get the benefits of order of operations between operators).

Basically, the thing about auto-boxing is just know it's there (actually, you can even get by and "inadvertently" use this feature without even knowing it exists or what it's called). There's no extra work on your part (actually, quite the opposite, there's loads less work).

This is why people don't generally use assembly all the time, or even worse hand-code out the machine code. It's because some computer scientist came along and decided "this is a lot of work. I wonder what's the easiest (or laziest) way I can get this done?"

Just for fun, here's how this operation would have to be carried out using z80 assembly (a very old assembly language, I know, but it demonstrates the point)

ld a, 5
ld b, 3
add a,b
ld d,a
ld a,5
ld b,3
sub b
ld b,a
ld a,d
 
multiplyLoop:
add a,d
dec b
jp nz, mulitplyLoop

Java's an all OOP language, so it's fairly difficult to write Java procedurally (not to say it isn't possible, but it's generally not something you would want to do)

In all reality, you only need to know 3 basic concepts about OOP:

1. Abstraction - "It doesn't matter what's actually happening, I just want to know how to use it"
2. Inheritance - "I get everything my ancestors have plus what I have"
3. Polymorphism - "I can look like me, or I can look like my parent/grand parent/etc, but I am still me!"

interfaces fall along the same lines as abstraction.