This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Arrays.asList(...) problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Arrays.asList(...) problem" Watch "Arrays.asList(...) problem" New topic

Arrays.asList(...) problem

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Hi Ranchers!

I've got a question about Arrays.asList(...) but basicaly I think it is valid also in other cases.

Check this piece of code:

The return type of #1 is as expected - List<Integer>, but the return type of #2 is List<int[]>.

Now, looking at the Arrays.asList() method signature we can see (taken from

So in the #1 we get because the Integer[] is equal to Integer...
In the #2 we got just as the int[] would not be equal to int...

On the other hand, it seems that int[] is treated as an valid argument for method which accepts int..., just like in code below:

So... what's going on in real? Why does argument "T... a" treats Integer[] in a proper way, while int[] doesn't? Did I miss something from K&B book, or did I make a mistake somewhere?

Thanks in advance for your replies!

Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

Very good question! I really had to think about it. It's because the T in asList(T... a) can only be an object and not a primitive.
But the int[] is an object (arrays extend object) therefor it does compile and it returns List<int[]>. I'm surprised there aren't overloaded methods available for primitives because other methods in the Arrays class do have them.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Thanks Wouter for your reply!

But then again - isn't the Integer[] also an object? Isn't every array an Object? Shouldn't it then also be treated as follows?

Edited: OK, I think I got it - so if the T can only be an Object it treats the Integer[] something like:

while the int[] treats like:

Thanks a lot Wouter!
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

You're really making me think I've tested some stuff and this is what I found:

Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

And if you add the printout of t array length in change method like this:

it will occur that test((Object)a) is, as expected, a single element list (this element is an Integer[] array object).
Sid Dev

Joined: Aug 31, 2010
Posts: 3
Hope this will clarify your doubts

The algorithm used by the compiler for the resolution of overloaded methods
incorporates the following phases:
1. It first performs overload resolution without permitting boxing, unboxing, or
the use of a varargs call.
2. If phase (1) fails, it performs overload resolution allowing boxing and unboxing,
but excluding the use of a varargs call.
3. If phase (2) fails, it performs overload resolution combining a varargs call,
boxing, and unboxing.

Source : Book By
Khalid A. Mughal
Rolf W. Rasmussen
Chapter 7
Piotr Nowicki
Ranch Hand

Joined: Jul 13, 2010
Posts: 610

Once again, thanks everybody for help :-)

Have you checked out Aspose?
subject: Arrays.asList(...) problem
It's not a secret anymore!