año justo, creado fuera de la colección, la JVM tiene que ponerlo a cero antes de que se rellene; el que la colección crea por dentro se puede rellenar directamente, sin ese paso. Está medido con detalle en el artículo de Aleksey Shipilëv, que es la referencia canónica cada vez que alguien reabre la discusión. ## El `toArray()` que devolvía lo que no debía Durante casi veinte años, esto daba una sorpresa: ```java List list = Arrays.asList("a", "b"); Object[] o = list.toArray(); System.out.println(o.getClass()); // hasta Java 8: class [Ljava.lang.String; o[0] = 42; // hasta Java 8: ArrayStoreException ``` El contrato de `Collection.toArray()` dice que devuelve un `Object[]`, pero la lista de `Arrays.asList` devolvía un `clone()` del arreglo de detrás, que era un `String[]` disfrazado. El tipo declarado cuadraba — gracias a la covarianza del post 08, un `String[]` *es* un `Object[]` — pero en cuanto alguien escribía otra cosa, `ArrayStoreException`. Se corrigió en Java 9 (JDK-6260652), y la corrección rompió a su vez el código que se había acostumbrado al error: `(String[]) list.toArray()` pasó a lanzar `ClassCastException`. La salida para los dos casos es la misma: `toArray(new String[0])` o, desde Java 11, `toArray(String[]::new)`. ## Detalles que ahorran un `NullPointerException` - **`args` nunca es `null` cuando el programa lo arranca el lanzador `java`.** Si lo ejecutas sin argumentos, recibe un arreglo de longitud cero, así que la comprobación `if (args == null)` sobra — salvo que alguien llame a `main(null)` a mano, que para eso es un método como cualquier otro. - **`Arrays.toString(null)` devuelve la cadena `"null"`**, y `Arrays.hashCode(null)` devuelve `0`. Ninguno de los dos lanza NPE, cosa que se agradece cuando lo que estás haciendo es depurar. - **Un arreglo varargs vacío tampoco es `null`** (post 09). ## `clone()`, el único que salió bien `Object.clone()` tiene mala prensa merecida: es `protected`, exige implementar `Cloneable`, no llama al constructor y devuelve `Object`. Con los arreglos, en cambio, funciona exactamente como uno esperaría: ```java int[] copy = original.clone(); // público, sin cast, sin configurar nada ``` La JLS lo define como público y con tipo de retorno covariante (sección 10.7), y hace justo lo que dice — aunque, como vimos más arriba, la reflexión no lo encuentre. El arreglo es el caso en el que el mecanismo de clonación de Java se comporta como debería haberse comportado en todas partes. ## A tener en cuenta - **Los descriptores aparecen en los sitios peores.** `[Ljava.lang.String;` en un `ClassCastException` o en un log de reflexión deja de ser jeroglífico cuando sabes leerlo. - **`Requested array size exceeds VM limit` no es "se acabó la memoria".** Confundirlos manda la investigación en la dirección contraria durante horas. - **El truco del `char[]` es una práctica de seguridad real**, no folclore: cualquier revisión seria de manejo de credenciales lo pide. ## Fuentes y lecturas recomendadas **Introductoria** - Javadoc de `PrintStream` — la lista de sobrecargas de `println`, donde se ve que `char[]` tiene la suya y ningún otro arreglo. **Profundidad técnica** - Ejercicios de Arreglos en Java — repositorio público con código relacionado. - JVMS SE 21, sección 4.3.2: Field Descriptors — la tabla oficial de la que salen `[I` y `[Ljava/lang/String;`, incluido el límite de 255 dimensiones. -

Curiosidades y rarezas de los arreglos

Andrés Segura