Java autoboxing/unboxing madness (2007)

Right. This is only tangentially to do with autoboxing, the same would happen for (true ? 1L : 0.0).

Because 1995.

Keep in mind that Java came out about 5 years before a certain similar language that has reference types. The designers of that language made some decisions based on trying to learn from things that didn't work out so well in Java.

To some extent both languages were trying to deal with C++'s having three different kinds of types: Atomics, objects and structs. If I had to tell a made-up story, I'd guess that Java's designers looked at that and decided structs were in many ways just a more limited version of classes with some confusing semantic quirks, and therefore decided to nix them. That left atomics and objects, and the rest is history.

C#'s folks then reconsidered it and realized that, from a high level perspective, atomics are really just a special case of structs. (Side note: still telling that made-up story.) So they kept structs, unified them with atomics in the language,* and let the compiler deal with the rest. It works well and seems like an obviously better way to do it, but I'm not sure that insight would have been so obvious in the moment.

* Edit: Oh, and made structs a subtype of System.Object. Unlike Java, .NET's more-or-less fully object-oriented.

I think a lot of it was for performance concerns. For math-heavy operations, the dealing with lots of objects caused quite a bit of garbage collection overhead. This is much less important now—they've optimized garbage collection to the point that it is often irrelevant—but it's still a concern in math-heavy applications.

Here's an article that goes into it in more detail: http://www.javaworld.com/article/2150208/java-language/a-cas...

  Why should I care

Let's say you were processing map data for OpenStreetMap, which has about 3,720,000,000 nodes [1], and for each node you want to store a latitude and a longitude.

If you use a pair of primitive ints for the latitude and longitude you'll need 8 bytes of memory per node, or 30 gigabytes total.

(Ignoring caching and assuming UseCompressedOops is enabled) Each boxed int will take 4 bytes for the primitive and 8 bytes of housekeeping overhead and class reference, rounded up to 16 bytes because memory boundaries must be divisible by 8, plus you'll need a reference to that object which is another 4 bytes.

So replacing those two primitive ints with boxed ints will take 40 bytes of memory per node, or 150 gigabytes total. And now you've got a 150 gigabyte heap to garbage collect :)

That memory increase is the difference between an EC2 instance that costs $1600/year and one that costs $13000 - and primitives will probably perform better as well.

And if you want to store more than two ints for each node, it could be the difference between an off-the-shelf EC2 server and needing to get hold of special high memory servers.

[1] https://www.openstreetmap.org/node/3720000000

When Java came out into the open, I had 16 MB of RAM in my 486 and that was more than most of my friends. A long take 4 bytes allocated on the stack so no GC overhead. A pentium 133 was bleeding edge and 64MB of RAM was Unix workstation territory.

In that backdrop, seemingly bad trade off get made for execution performance and to compile the code in a reasonable amount of time. More accurate would've been that the decision has not aged very well.

Whoever wrote this obviously wasn't around for the pre-boxing Java experience. Want to store a list of ints? Box on the way in, box on the way out.

So. Much. Typing. I'll take the occasional "gotcha" that's not terribly difficult to diagnose or fix over the world we had before.

In general, it is good. But when combined with generics, weird stuff happens. Say you have some generic collection of Integer (e.g., Map<Integer, String>) and you retrieve some autoboxed value that was coerced into a Long and you try to use that as a key. You might get a null result where you would expect otherwise. It makes you want to pull your hair out and undermines the confidence that type safety gives you in general.

Autoboxing and generics are clearly bolted onto Java and it would be designed differently if they were there in the beginning. This makes me doubtful when Go adherents say that they can just add generics later.

It still comes up quite often. Autoboxing and type erasure are two of the biggest mistakes that have been inflicted upon the Java language after its original release. Not knowing about them will lead to a world of hurt.

They should have killed the primitive/object distinction, turning the primitives into stack-allocated objects and rewritten the collections libraries. But no, syntactic sugar is better than actually fixing the problem for those that want a fix.