Be careful if you use Comparator<Integer>. Because remember that if you compare Integers (not int's) you're comparing objects. The Integer class has an Integer cache so the return values may be unexpected. A way to "solve" this is to make them int's:
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
I understand. You should use the equals() method for objects - don't have the to turn them into ints, but it would be easy to use == by mistake and think your code was working if you only tested with low numbers.
I just did a test and the same thing happens with the auto-boxing in Arraylists... this one's more confusing because Integer objects aren't even mentioned:
Luigi Plinge wrote:...the same thing happens with the auto-boxing in Arraylists... this one's more confusing because Integer objects aren't even mentioned...
Unlike arrays, Collections (like Lists) cannot hold primitive values. This is why the autoboxing happens.
Although this will compile and run without mentioning Integer types, you will probably see compiler warnings about unchecked or unsafe operations. Since Java 5, the safer way is to specify a type for the Collection...
...this allows the compiler to insert all the necessary casting and avoid surprises about what your Collection actually contains.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Sorting Of Array From Even Number To Odd Number