Java enum valueof
Nota: Este post es parte de una serie sobre D8 y R8, el nuevo dexer y optimizador de Android, respectivamente. Para una introducción a D8 lea “El soporte de Java 8 de Android”. Para una introducción a R8 lea “Optimización R8: Staticization”.
Las enumeraciones son (y siempre han sido) una forma recomendada de modelar un conjunto fijo de constantes. Lo más habitual es que un enum sólo proporcione un conjunto de constantes posibles y nada más. Pero al ser clases completas, los enums también pueden llevar métodos y campos de ayuda (tanto de instancia como estáticos) o incluso implementar interfaces.
Una optimización común para las enum en las herramientas que realizan la optimización de todo el programa es reemplazar las ocurrencias simples (es decir, las que no tienen campos, métodos o interfaces) con valores enteros. Sin embargo, hay otras optimizaciones aplicables a todos los enums que todavía están disponibles.
Cada constante de enum tiene un ordinal() que devuelve su posición en la lista de todas las constantes. Dado que el rango ordinal es siempre [0, N), puede utilizarse para indexar en otras estructuras de datos basadas en cero, como arrays o incluso bits. El uso más común es en realidad por el propio compilador de Java para las sentencias switch sobre enums.
Valor inicial del ordinal de Java
En el lenguaje Java, todas las enumeraciones declaradas con la palabra clave enum heredan automáticamente de la clase genérica Enum. Según la documentación, la forma general de declarar la clase Enum es la siguiente:
En la clase Enum, el método clone() tiene por objeto evitar que se realice la operación de clonación de la enumeración. Este método está oculto, por lo que no será posible llamarlo para la enumeración. La declaración del método clone() en la clase Enum es la siguiente
Cuando se declara una enumeración y se le asigna un valor constante, se crea un nuevo objeto cada vez. Cada constante asignada es un objeto separado e independiente, por lo que no tiene sentido clonar este objeto, puesto que ya está siendo clonado.
las enumeraciones t1 y t2 apuntan a diferentes ubicaciones en la memoria. Es decir, no se ha producido la asignación de referencias, como ocurre con las instancias de clase. Este hecho demuestra el resultado de la salida del valor de t2 después de cambiar el valor en la enumeración t1
Como se puede ver en el resultado, el valor de la enumeración t2 no ha cambiado, es decir, la clonación se realiza automáticamente. Por lo tanto, no tiene sentido definir un método clone() para trabajar con las enumeraciones.
Java enum tostring
¿Hay algún problema con el uso del método ordinal() para comprobar la “jerarquía” entre los miembros del enum? Quiero decir – hay alguna desventaja al usarlo excluyendo la verbosidad, cuando alguien puede cambiar accidentalmente el orden en el futuro.
Como sugiere Joshua Bloch en Effective Java, no es una buena idea derivar un valor asociado a un enum a partir de su ordinal, porque los cambios en el orden de los valores del enum podrían romper la lógica que has codificado.
En este caso, el uso de enums no es probablemente la mejor opción ya que puede romper frecuentemente el código cliente que lo utiliza y además obliga a recompilar, reempaquetar y volver a desplegar la aplicación cada vez que se modifica un valor enum.
Ten en cuenta que sólo puedes utilizar valores enum que hayan sido declarados léxicamente antes del que intentas declarar, por lo que esto sólo funciona si tus relaciones forman un grafo dirigido acíclico (y el orden en que los declaras es una ordenación topológica válida).
Y en nuestro caso funciona perfectamente. Si no hubiéramos tenido un enum para hacerlo habríamos tenido que renumerar todos los órdenes de los filtros añadiéndoles 1 (o a las constantes que los almacenan). Cuando tenemos un enum sólo hay que añadir una línea en el enum en el lugar adecuado y utilizar el ordinal. No tenemos que cambiar el código en muchos lugares y tenemos la estructura clara de orden para todos nuestros filtros en un solo lugar.
Ordinal() java
Una alternativa sugerida por JDK-8252556 es utilizar el hashCode() del nombre de la constante enum en lugar de su ordinal. No está claro si esto es mejor. Los valores ordinales son únicos dentro de un tipo enum, por lo que probablemente ya son tan resistentes a las colisiones como sea posible.
Una razón expuesta en JDK-8252556 para esto es “un código hash consistente es casi estrictamente requerido por las implementaciones de generadores de claves de caché”. El requisito implícito aquí es que el código hash sea consistente de una ejecución de la JVM a la siguiente y también presumiblemente a través de las implementaciones del JDK. Encuentro esto remotamente plausible pero no convincente. Usar el hashCode de un objeto para propósitos fuera de la JVM parece estar cruzando fuera de su uso previsto.
Como se ha señalado, Object.hashCode() ya establece: “Este entero no tiene por qué permanecer consistente de una ejecución de una aplicación a otra ejecución de la misma aplicación”. Por supuesto, esto podría ser anulado para las constantes de enum, como ya lo es para otras clases que tienen hashCodes estrechamente especificados, como String y las primitivas en caja. La cuestión es si merece la pena hacerlo.
