Предоставление реализации по умолчанию compareTo, которая использует порядок исходного кода, нормально; сделать это окончательным было ошибкой со стороны Sun. Порядок декларации уже учитывается порядковым номером. Я согласен с тем, что в большинстве ситуаций разработчик может просто логически упорядочить свои элементы, но иногда нужно, чтобы исходный код был организован таким образом, чтобы удобство чтения и обслуживание были первостепенными. Например:
KILOBYTE (false, true, 3, "kB"),
MEGABYTE (false, true, 6, "MB"),
GIGABYTE (false, true, 9, "GB"),
TERABYTE (false, true, 12, "TB"),
PETABYTE (false, true, 15, "PB"),
EXABYTE (false, true, 18, "EB"),
ZETTABYTE(false, true, 21, "ZB"),
YOTTABYTE(false, true, 24, "YB"),
KIBIBYTE(false, false, 10, "KiB"),
MEBIBYTE(false, false, 20, "MiB"),
GIBIBYTE(false, false, 30, "GiB"),
TEBIBYTE(false, false, 40, "TiB"),
PEBIBYTE(false, false, 50, "PiB"),
EXBIBYTE(false, false, 60, "EiB"),
ZEBIBYTE(false, false, 70, "ZiB"),
YOBIBYTE(false, false, 80, "YiB");
Вышеупомянутый порядок выглядит хорошо в исходном коде, но не так, как считает автор compareTo. Желаемое поведение compareTo состоит в том, чтобы упорядочивать по количеству байтов. Упорядочивание исходного кода, которое могло бы сделать это, ухудшает организацию кода.
Мне, как клиенту перечисления, наплевать, как автор организовал свой исходный код. Однако я хочу, чтобы их алгоритм сравнения имел какой-то смысл. Sun без надобности связывает разработчиков исходного кода.