timsort (original) (raw)

Joshua Bloch jjb at google.com
Tue Jul 7 16:59:16 UTC 2009

Chris,

On Tue, Jul 7, 2009 at 2:51 AM, Christopher Hegarty -Sun Microsystems Ireland <Christopher.Hegarty at sun.com> wrote:

Hi Martin,

Sorry for joining the party late... I think adding the system property should take care of the compatibility issues, at least giving the user the ability to revert to the old behavior if they so choose. I have a few minor comments ( if these issue have been discussed already I apologize ): 1) Should we update the Arrays class description and appropriate sort methods to now refer to timsort instead of saying: "The sorting algorithm is a modified mergesort...". I know this is not strictly necessary, but you must have considered it already, right?

No. I totally missed it. Good catch!

2) With the addition of @throws IllegalArgumentException, this condition cannot be met with the old merge sort right, i.e. running with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying that all bets are off when running with this property set?

Others have already commented on this; this @throws clause makes no promises, but calls out a (desirable) behavior that the new implementation might exhibit (and the old one never will) when the user has violated a fundamental contract (hence all bets are off).

      Josh

P.S. Thanks all, and especially Martin, for shepherding this work into the JDK! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/feb76705/attachment.html>

More information about the core-libs-dev mailing list