

Java autoboxing/unboxing madness (2007) - xg15
http://arstechnica.com/civis/viewtopic.php?f=20&t=168180

======
aeonsky
JLS:
[https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.htm...](https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.25)

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
Right. This is only tangentially to do with autoboxing, the same would happen
for (true ? 1L : 0.0).

------
charriu
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?

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

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

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

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

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

