不幸的是并不是每件事都尽如人意。举个例子，现在将一个Java数组转换为List。当然，我们可以使用Arrays.asList方法，但是如果没有慎重思考就随便使用几乎肯定会产生令人讨厌的意外。考虑完下面这段程序并预测其输出你就明白我的意思了：

由于Javadoc对Arrays.asList的说明相当模糊，对你来说预测出程序的运行结果可能有点困难，下面我们来一步步的揭晓答案：

• 第9行就像我们根据API所预测的那样在我们的控制台输出了“[a,b]”，这正是我们乐意看到的。
• 第12行也一样如预期那样输出了“[1,2]”。
• 第15行就不同了，当然这里不是说15与12的不同，而是一个是int另一个是Integer，因此在我们的控制台打印出了类似这样的结果“[[I@39172e08]”，这就不再如预期那样了。我们得到一个包含数组中标识每个元素唯一性的地址串的list，而不是包含两个Integer对象的list。
• 看到上面的结果后，对于第18行输出的类似“[[Ljava.lang.String;@20cf2c80, c]”这样的结果就不会感到惊奇了。

但是发生了什么呢？前两个打印语句与我们预期的结果相同，因Java语言规范规定了调用一个声明为foo(T… t)的方法，比如foo(new T[]{bar,baz})等同于foo(bar,baz)这样的调用。在Arrays.asList方法中T是参数类型，因此它必须为一个Object 类型，但是int不是，而int[]却是。这就是为什么第16行的声明等同于 Arrays.asList(new Object[] { new int[] { 1, 2 } })。

最后也是非常重要的一点，在第19行的声明从一开始就产生了调用问题。我们告诉编译器我们需要一个包含String数组和字符串的list，正如我们预期的那样我们得到了我们想要的东西。

到现在为止解释了这么多，但是我们还可以从中学到更多的东西：问题的真正来源并不是可变参数设计的很糟糕；相反的我认为这个设计很好。关于这个问题在《Effective Java2》第 42项规范中已经解释地很清楚了，Arrays.asList违反了该项规范，事实上Arrays.asList作为一个反面教材，告诉了我们在使用Java的可变参数设计API时为什么要非常小心。在这里我不会再重复那篇文章里的回答，但是你自己确实需要亲自去读一下它，但是考虑到完整性我必须指出 上面有问题的声明在使用Java1.4的编译器下编译的时候就会报错，这是相当好的。现在我们仍然会使用Arrays.asList，但是为了安全要求我 们知道所面临的问题的复杂性。下面是在将数组转换为lists的时候我们需要遵循的规则，做到这些可以确保没有任何意外的情况发生：

• 如果你要将一个数组转换为list时仅仅是要将其转换为一个string，那么最好使用Arrays.toString代替上面的方法吧。即使对于基本类型的数组该方法也不会出现任何问题。
• 如果你打算将一个基本类型的数组转换为所对应的封装类型的list，使用Apache Commons Lang吧，可能你的项目正在使用它，类似下面这样使用ArrayUtils.toObject：

• 如果你打算将一个引用类型的数组转换为list，可以直接使用Arrays.asList：

不要忘了告诉和你一起工作的人以确保他们不和你犯同样的错误。当然，你也可以选择仅仅记住那些使用Arrays.asList方法时可能出现问题的地方，并使用普通的for循环来代替，但是那会使你的代码很杂乱，还会带来性能方面的问题。