Java autoboxing/unboxing madness (2007)

http://arstechnica.com/civis/viewtopic.php?f=20&t=168180

by xg15 • 11 years ago

33 16 11 years ago

charriu• 11 years ago

I personally never understood why java has built in types vs. reference types. Why should I care, instead of just letting the compiler handle that for me?

gutnor• 11 years ago

Because 1995.

bunderbunder• 11 years ago

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.

Sharlin• 11 years ago

C++ doesn't really make a difference between builtin and user-defined data types. They all have value semantics, and a lot of effort has been spent to make user-defined types able to mimic builtin types as closely as possible. Classes and structs have no semantic differences besides default visibility of member names. For reference semantics, you use explicit references.

Java wanted to enforce reference semantics (and heap storage) for classes, but still wanted to retain value semantics (and stack storage) with fundamental types for performance reasons. The result is the mess we have now.

pjmlp• 11 years ago

Many languages older than Java do the said conversion between value and reference types.

They just wanted to simplify the compiler.

organsnyder• 11 years ago

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

michaelt• 11 years ago

  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

acveilleux• 11 years ago

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.

aeonsky• 11 years ago

JLS: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...

Otherwise, if the second and third operands have types that are convertible (§5.1.8) to numeric types, then there are several cases:

... binary numeric promotion (§5.6.2) is applied to the operand types, and the type of the conditional expression is the promoted type of the second and third operands.

... If either operand is of type double, the other is converted to double.

gefh• 11 years ago

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

akshayB• 11 years ago

Few years back when I worked in Java, this was the most asked question in technical interviews.

photosinensis• 11 years ago

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.

tsotha• 11 years ago

They should have killed the primitive/object distinction, turning the primitives into stack-allocated objects and rewritten the collections libraries.

That would have been a mistake, because it would have made Java unreasonably inefficient for manipulating large data sets. You really need both, which is why they included both originally.

Autoboxing is a problem in that it allows you to pretend you don't have to check for nulls when you really should be checking for nulls. If I had my druthers I'd forbid autoboxing on my projects.

aikah• 11 years ago

I'm not a java guy but having to deal with type conversion in Go isn't auto-boxing a good thing ?

mmastrac• 11 years ago

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.

mcculley• 11 years ago

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.

Java autoboxing/unboxing madness (2007)

Related Stories