Proporcionar una implementación predeterminada de compareTo que utilice el orden del código fuente está bien; hacerla definitiva fue un paso en falso por parte de Sun. El ordinal ya representa el orden de declaración. Estoy de acuerdo en que, en la mayoría de las situaciones, un desarrollador puede simplemente ordenar lógicamente sus elementos, pero a veces uno quiere que el código fuente esté organizado de una manera que haga que la legibilidad y el mantenimiento sean primordiales. Por ejemplo:
//===== SI BYTES (10^n) =====//
/** 1,000 bytes. */ KILOBYTE (false, true, 3, "kB"),
/** 106 bytes. */ MEGABYTE (false, true, 6, "MB"),
/** 109 bytes. */ GIGABYTE (false, true, 9, "GB"),
/** 1012 bytes. */ TERABYTE (false, true, 12, "TB"),
/** 1015 bytes. */ PETABYTE (false, true, 15, "PB"),
/** 1018 bytes. */ EXABYTE (false, true, 18, "EB"),
/** 1021 bytes. */ ZETTABYTE(false, true, 21, "ZB"),
/** 1024 bytes. */ YOTTABYTE(false, true, 24, "YB"),
//===== IEC BYTES (2^n) =====//
/** 1,024 bytes. */ KIBIBYTE(false, false, 10, "KiB"),
/** 220 bytes. */ MEBIBYTE(false, false, 20, "MiB"),
/** 230 bytes. */ GIBIBYTE(false, false, 30, "GiB"),
/** 240 bytes. */ TEBIBYTE(false, false, 40, "TiB"),
/** 250 bytes. */ PEBIBYTE(false, false, 50, "PiB"),
/** 260 bytes. */ EXBIBYTE(false, false, 60, "EiB"),
/** 270 bytes. */ ZEBIBYTE(false, false, 70, "ZiB"),
/** 280 bytes. */ YOBIBYTE(false, false, 80, "YiB");
El orden anterior se ve bien en el código fuente, pero no es como el autor cree que debe funcionar compareTo. El comportamiento deseado de compareTo es que el orden sea por número de bytes. El ordenamiento del código fuente que haría que eso suceda degrada la organización del código.
Como cliente de una enumeración, no podría importarme menos cómo el autor organizó su código fuente. Sin embargo, quiero que su algoritmo de comparación tenga algún tipo de sentido. Sun ha puesto innecesariamente a los escritores de código fuente en un aprieto.