Is auto(un)boxing good style?

Thread view:

Patricia Shanahan - 30 Mar 2007 17:59 GMT

Here is a sample program that uses auto-boxing and auto-unboxing:

public class AutoBoxQuestion {
public static void main(String[] args) {
/* This does seem better than writing out
{new Long(1), new Long(2), new Long(3), new Long(4)}*/
Long[] data = new Long[]{1L,2L,3L,4L};
long total = 0;
for(Long val: data){
// Or should this be val.getLong()?
total += val;
}
System.out.println("Total is "+total);
}
}

Is it good style to depend on the auto-boxing and auto-unboxing?

My real program is a little more complicated, involving retrieving
results from a List<Future<Long>>, but contains the same principle of
adding up values represented as Long objects.

Patricia

Reply to this Message

Tom Hawtin - 30 Mar 2007 18:55 GMT

> Here is a sample program that uses auto-boxing and auto-unboxing:
>
[quoted text clipped - 3 lines]
> {new Long(1), new Long(2), new Long(3), new Long(4)}*/
> Long[] data = new Long[]{1L,2L,3L,4L};

You don't want to be using new Long. FindBugs will flag it as being
inefficient compared to Long.valueOf.

long[] would be better. It's a shame Java has primitives. OTOH, if it
didn't have primitives (and didn't introduce the idea of
non-nullability), pretty much any expression involving a long could NPE.

> long total = 0;
> for(Long val: data){
> // Or should this be val.getLong()?
> total += val;

It shouldn't be using getLong, no. (longValue is more likely).

> }
> System.out.println("Total is "+total);
> }
> }
>
> Is it good style to depend on the auto-boxing and auto-unboxing?

It's not a feature I'm particularly keen on, but it is part of the
language now. You should be able to expect that other programmers know
about it, and no to be careful about introducing possible NPEs. It's now
a commonly used part of the language - not to use it (in obvious
situations) would be unidiomatic.

Why would you be worried about mixing up long and Long?
* Might use == to compare values, but actually compare references.
* Might use == to compare references, but actually compare values.
* NPEs, if the value could be null.
* Potential performance impact.

Honestly, I don't think any of those are, in practice, big issues.

There is one significant advantage auto-unboxing has over
manual-unboxing: No casting goes on. Long gets unboxed to long, and the
compiler will complain if you assign that to an int. Have somewhere
buried in your code .intValue, and even if you assign it to a long the
value will be quietly truncated. Fixed length integers should have died
twenty years ago.

Tom Hawtin

Reply to this Message

Kai Schwebke - 30 Mar 2007 18:59 GMT

Patricia Shanahan schrieb:

> Here is a sample program that uses auto-boxing and auto-unboxing:

...

> Is it good style to depend on the auto-boxing and auto-unboxing?

Yes. Having both basic integral types and real objects in Java
is the unstylish thing. Auto-boxing and unboxing is a hack for this
design flaw of Java to allow better styled code.

Kai

Signature

C++: an octopus made by nailing extra legs onto a dog.
* Steve Taylor

Reply to this Message

Is auto(un)boxing good style?

Free Magazines