Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Arrays.asList(...) problem

 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://download.oracle.com/javase/6/docs/api/java/util/Arrays.html):



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!

Cheers.
 
Wouter Oet
Saloon Keeper
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2700
IntelliJ IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're really making me think I've tested some stuff and this is what I found:

 
Piotr Nowicki
Ranch Hand
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 611
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Once again, thanks everybody for help :-)

Cheers!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic