Cerraste el módulo 4 con una promesa y una confesión. La promesa: los arrays provisionales de BiblioTech se convertirán en colecciones. La confesión: cada vez que el proyecto necesita guardar muchas cosas, recurre a un Material[] catalogo = new Material[10] que hay que copiar entero para añadir un elemento y recorrer completo para encontrar uno. Antes de sustituirlos conviene entenderlos de verdad, porque el array no desaparece: ArrayList es un array por dentro, HashMap es un array de cubetas, ArrayDeque es un array circular, y String es un array de bytes. Todo el Framework de Colecciones que verás en las ocho lecciones siguientes está construido sobre arrays.

Un arreglo (o array, el término que usaremos casi siempre porque es el que verás en todo el código real) es la estructura de datos más primitiva y más rápida de Java: un bloque contiguo de memoria, de tamaño fijo, que guarda elementos del mismo tipo y permite acceder a cualquiera de ellos por su posición en tiempo constante. Esas cuatro palabras —contiguo, fijo, homogéneo, constante— explican a la vez toda su potencia y todas sus limitaciones. En esta lección las verás en detalle, aprenderás por fin el bucle for-each que quedó pendiente en el módulo 2, dominarás la clase de utilidades Arrays y terminarás con una lista clara de las cosas que un array no puede hacer: exactamente la lista de motivos por los que existe el Framework de Colecciones.

1. Qué es realmente un array
2. Declarar, crear e inicializar
3. Valores por defecto
4. Índices, length y los límites del array
5. Recorrido con for clásico
6. El bucle for-each
7. Arrays de primitivos frente a arrays de objetos
8. Arrays multidimensionales y dentados
9. La clase Arrays
10. Copiar arrays
11. Varargs por dentro es un array
12. Aplicación: el catálogo de BiblioTech
13. Las limitaciones que motivan las colecciones
14. Errores Comunes y Consejos
15. Ejercicios

Un array es un bloque contiguo de memoria reservado de una vez, dividido en celdas del mismo tamaño. Cuando escribes:

la JVM reserva en el heap espacio suficiente para cinco enteros (cinco veces cuatro bytes) más una pequeña cabecera con el tipo y la longitud. Todas las celdas están pegadas una detrás de otra:

Esa contigüidad es la clave de todo. Para leer diasRetraso[3], la JVM no busca nada: calcula direccion_base + 3 * 4 bytes y lee. Una multiplicación y una suma, siempre el mismo trabajo, dé igual que el array tenga cinco elementos o cinco millones. A eso lo llamamos acceso en tiempo constante, o O(1).

Notación O(): cómo leerla. A lo largo de este módulo compararás estructuras de datos por su coste. La notación O() describe cómo crece el tiempo de una operación cuando crece el número de elementos n, ignorando constantes y detalles de máquina. O(1) significa tiempo constante: da igual que haya 10 o 10 millones de elementos, cuesta lo mismo. O(n) significa lineal: con el doble de elementos, el doble de tiempo (recorrer un array entero). O(log n) significa que doblar los elementos añade solo un paso más (búsqueda binaria: con un millón de elementos, unos 20 pasos). O(n²) significa que doblar los elementos cuadruplica el tiempo (dos bucles anidados; es lo que hace hoy el informePorTipo de BiblioTech). No es una medida de segundos, es una medida de cómo escala.

Y hay una segunda ventaja menos obvia: la localidad de caché. Los procesadores modernos no leen la memoria byte a byte, sino en bloques (líneas de caché de 64 bytes típicamente). Al leer diasRetraso[0], el procesador trae también los siguientes elementos "gratis". Por eso recorrer un array es dramáticamente más rápido que recorrer una estructura cuyos elementos estén dispersos por la memoria: lo verás con números en 05-04, cuando compares ArrayList con LinkedList.

Las tres propiedades que definen un array en Java:

Ese tercer punto sorprende a mucha gente: un array es un objeto, aunque no exista una clase Array que puedas ver. int[], String[] y Material[] son tipos reales que heredan de Object, por lo que un array tiene hashCode(), toString() y getClass(). Eso tendrá consecuencias importantes en el apartado 9.

Son tres operaciones distintas y conviene no confundirlas.

Declarar solo crea la variable que guardará la referencia. No hay array todavía:

Usa siempre la primera forma. La segunda compila, pero oculta información: en Material catalogo[], otro;, catalogo es un array y otro no lo es, lo que es una fuente clásica de confusión.

Crear reserva la memoria con new, y aquí es donde se fija el tamaño para siempre:

El tamaño puede ser una variable calculada en ejecución, lo que sí es flexible:

Lo que no puede es cambiar después. seleccion medirá cuantos para siempre.

Inicializar con literal crea y rellena en una sola expresión, y el tamaño se deduce de los elementos:

Esta forma abreviada solo vale en la declaración. Si quieres asignar un array literal a una variable ya declarada, o pasarlo directamente como argumento, necesitas la forma completa con new:

Al crear un array con new, Java rellena todas las celdas con el valor por defecto del tipo. Esto no es un detalle menor: significa que un array recién creado nunca contiene basura, a diferencia de lo que ocurre en C.

La consecuencia práctica más importante es la última fila. Un new Material[10] no contiene diez materiales: contiene diez referencias null. Sigue siendo tu trabajo llenarlas:

Y también explica la trampa clásica de contar elementos: si creas new Material[10] y solo rellenas tres, catalogo.length vale 10, no 3. El array no sabe cuántas celdas has usado; por eso todo el BiblioTech del módulo 4 arrastra variables auxiliares como int n = 0 para llevar la cuenta a mano. Las colecciones eliminan exactamente ese problema.

Los índices de un array van de 0 a length - 1. Que empiecen en 0 no es un capricho: el índice es literalmente el desplazamiento desde el inicio del bloque. El primer elemento está a distancia cero de la base.

length es un atributo, no un método. Se escribe array.length, sin paréntesis. Es una de las inconsistencias históricas de Java que más confusión genera, porque para String es un método (texto.length()) y para las colecciones es otro método distinto (lista.size()). Memoriza los tres:

Si accedes fuera de rango, la JVM lo detecta y lanza ArrayIndexOutOfBoundsException:

Esto es una virtud, no un defecto: Java comprueba cada acceso y detiene el programa en el punto exacto del error, en lugar de leer memoria ajena silenciosamente como haría C. El coste de esa comprobación es mínimo y el compilador JIT la elimina cuando puede demostrar que el índice es seguro. Cómo capturar y tratar esa excepción es el tema del módulo 6; por ahora, evítala comprobando los límites antes de acceder.

El bucle for que conoces desde 02-02 es la forma completa de recorrer un array, y sigue siendo la correcta cuando necesitas el índice:

Tres detalles que evitan la mayoría de los errores de recorrido:

• i < multas.length, nunca i <= multas.length. El último índice válido es length - 1.
• Usa multas.length, no una constante literal como 4. Si mañana el array crece, el bucle se adapta solo.
• Empieza en 0, salvo que tengas un motivo explícito.

El for clásico es imprescindible cuando el recorrido necesita algo más que los valores:

Esa última es la más importante de recordar para el apartado siguiente.

En el módulo 2 se pospuso el for-each porque no tenía sentido explicarlo sin algo que recorrer. Ya lo tienes.

El bucle for mejorado o for-each (Java 5) recorre todos los elementos de un array o de cualquier objeto Iterable —lo que incluye todas las colecciones que verás en este módulo— sin gestionar índices:

Se lee literalmente "para cada elemento de tipo Tipo en coleccionOArray". Los dos puntos se pronuncian "en".

Compara las dos versiones del mismo recorrido:

Y con objetos del proyecto, donde brilla de verdad:

• Menos código y menos errores. Desaparecen las tres fuentes clásicas de fallo: empezar en 1, terminar en <=, olvidar el i++ (bucle infinito).
• Imposible salirse de rango. No hay índice que equivocarse: ArrayIndexOutOfBoundsException no puede ocurrir.
• Expresa la intención. "Recorro todos los elementos, uno por uno, hacia delante." Quien lee tu código lo sabe al instante.
• Funciona igual con arrays y con colecciones. El mismo bucle sirve para Material[] y para List<Material>, lo que hará indoloro el refactor del apartado 12.

Y ahora las tres cosas que no puede hacer, que son la razón de que el for clásico siga existiendo:

1. No te da el índice. Si necesitas numerar, comparar con el vecino o escribir en la posición i, necesitas el for clásico (o llevar un contador aparte, que es exactamente lo que el for-each intentaba evitar).

2. No permite modificar la celda del array. Esta es la limitación que más se malinterpreta, así que vale la pena verla con precisión:

La variable n es una copia del valor de la celda (paso por valor, 03-03). Reasignarla cambia la copia, no el array. Lo mismo ocurre con objetos:

m es una copia de la referencia. Reasignarla apunta la copia a otro objeto; la celda del array sigue apuntando al original.

Pero sí puedes modificar el objeto al que apunta, porque ahí no reasignas nada, invocas métodos sobre el mismo objeto:

La regla, en una línea: el for-each no puede cambiar a qué apunta cada celda, pero sí puede cambiar el estado del objeto apuntado.

3. Solo va hacia delante y de uno en uno. No hay recorrido inverso, ni saltos, ni recorridos parciales.

Usa for-each por defecto y baja al for clásico solo cuando necesites lo que el for-each no da. En 05-02 verás que el for-each no es una construcción mágica: el compilador lo traduce a un for clásico cuando recorre un array, y a un Iterator cuando recorre una colección.

Aquí está la diferencia estructural que explica la mitad de las sorpresas con arrays: qué guarda realmente cada celda.

En un array de primitivos, la celda contiene el valor:

En un array de objetos, la celda contiene una referencia al objeto, que vive en otro sitio del heap:

De ese diagrama se derivan cuatro consecuencias que conviene tener muy claras:

1. Un array de objetos es más pequeño de lo que parece pero cuesta más recorrer. Las celdas solo guardan referencias (4 u 8 bytes), pero seguir cada referencia implica un salto a otra zona del heap, lo que rompe la localidad de caché del apartado 1.
2. Dos celdas pueden apuntar al mismo objeto (aliasing, 03-02). catalogo[2] = catalogo[0]; no copia el libro: crea un segundo camino hacia él. Modificarlo por una vía se ve por la otra.
3. null es un valor legítimo en las celdas, y cada acceso a catalogo[i].algo() puede lanzar NullPointerException si esa celda nunca se rellenó.
4. El array es covariante, y eso tiene una trampa. Material[] acepta cualquier subclase de Material (Libro, Revista, Dvd), lo que es cómodo y es lo que permite el catálogo polimórfico. Pero también permite esto:

El compilador lo acepta porque Libro[] es subtipo de Object[], pero la JVM comprueba el tipo real en cada escritura y lanza ArrayStoreException. Es un agujero de seguridad de tipos que Java 1.0 aceptó por pragmatismo y que los genéricos corrigieron: List<Libro> no es un List<Object>, precisamente para que ese error se detecte al compilar. La teoría completa (invarianza, comodines, borrado de tipos) es la lección 10-01.

En Java no existen los arrays bidimensionales de verdad: lo que existe son arrays cuyos elementos son, a su vez, arrays. Entender eso resuelve todas las dudas de golpe.

Esto crea un array de 3 elementos, cada uno de los cuales es una referencia a un array de 12 enteros:

El acceso lleva dos índices, en orden fila-columna:

El recorrido natural son dos bucles anidados, uno por dimensión:

O, si no necesitas los índices, con for-each anidado:

Fíjate en el tipo de la variable del bucle externo: int[] fila, no int. Cada elemento de un int[][] es un int[].

También hay inicialización literal, y aquí se ve claramente que son arrays de arrays:

Como cada fila es un array independiente, las filas pueden tener longitudes distintas. A eso se le llama array dentado o jagged:

Observa la sintaxis new String[3][]: se indica el número de filas y se deja la segunda dimensión vacía, porque cada fila se creará después con su tamaño propio. Si dejas las filas sin crear, valen null, y acceder a prestamosPorEmpleado[0][0] daría NullPointerException.

Esta estructura —"para cada empleado, una lista de títulos de longitud variable"— es justo la que en 05-05 sustituirás por un Map<Empleado, List<Prestamo>>, mucho más expresivo y sin índices numéricos que mantener sincronizados con otro array de nombres.

java.util.Arrays es una clase de utilidades con métodos estáticos que resuelven casi todo lo que necesitas hacer con arrays. Es de las primeras cosas que hay que importar en cualquier programa serio:

Un array es un objeto que no sobrescribe toString(), así que imprimirlo directamente muestra la representación de Object de 03-09 (nombre del tipo, arroba, hash en hexadecimal):

Para arrays de más de una dimensión, toString no basta —imprimiría la referencia de cada fila—, y hace falta deepToString, que baja recursivamente:

Arrays.toString es tu herramienta número uno para depurar arrays. Úsala en cada traza.

Arrays.sort ordena el array en el sitio (in place): modifica el array recibido y no devuelve nada.

Con objetos, hay dos variantes. Sin Comparator, exige que los elementos implementen Comparable —lo que hace Ficha, según viste en 04-07— y usa su orden natural:

Y con un Comparator, que es donde se conecta todo el módulo 4:

Hay además una variante que ordena solo un rango, útil cuando el array tiene celdas sin usar al final:

La teoría completa —el contrato de compareTo, la estabilidad, qué algoritmo usa Java— es la lección de cierre de este módulo, 05-09.

Busca un elemento con búsqueda binaria: mira el elemento central, descarta media mitad y repite. Coste O(log n): en un array de un millón de elementos, unas veinte comprobaciones en lugar de un millón.

Dos advertencias esenciales:

• El array debe estar ordenado previamente, con el mismo criterio con el que buscas. Sobre un array desordenado el resultado es basura, y no hay ningún aviso.
• El valor negativo no es "-1 y ya está": es -(punto_de_insercion) - 1. En el ejemplo, -4 significa que 400 iría en el índice 3. Si quieres el punto de inserción: int pos = -resultado - 1;.

Rellena todo el array (o un rango) con el mismo valor:

copyOf crea un array nuevo del tamaño indicado, copiando lo que quepa y rellenando el resto con el valor por defecto:

Este es exactamente el truco que BiblioTech lleva usando desde el módulo 3 para "hacer crecer" un array, y también, literalmente, lo que hace ArrayList por dentro (05-03).

copyOfRange copia un tramo, con el límite inferior incluido y el superior excluido:

Aquí hay una trampa que cuesta horas a mucha gente. Como un array no sobrescribe equals, comparar dos arrays con == o con .equals() compara referencias, no contenidos:

Y para arrays de más de una dimensión, Arrays.equals compara las filas por referencia y también falla; hace falta deepEquals:

Lo mismo ocurre con el hash: usa Arrays.hashCode y Arrays.deepHashCode, nunca array.hashCode(), si vas a meter arrays en estructuras basadas en hash (que además es una idea que 05-05 te desaconsejará con argumentos).

Arrays.asList crea una List a partir de un array, y es tentador porque parece la conversión obvia. Pero devuelve una vista de tamaño fijo respaldada por el array original, no una lista normal:

Si quieres una lista de verdad, independiente y modificable, envuelve la vista:

Y una trampa adicional que aparece con primitivos: Arrays.asList es genérico y los genéricos no aceptan tipos primitivos, así que un int[] se interpreta como un único elemento:

Con Integer[] funcionaría como esperas. La causa profunda —los genéricos solo operan sobre tipos referencia— se explica en 10-01.

Hay cuatro formas de copiar, y elegir mal es una fuente habitual de errores sutiles.

La primera fila es el error de bulto: Material[] a = original; crea un segundo nombre para el mismo array. Escribir a[0] = otro; cambia también original[0]. Es el aliasing de 03-02 aplicado a arrays, y por eso el constructor de Catalogo hace Arrays.copyOf(materiales, materiales.length): copia defensiva (03-07) para que quien construyó el array no pueda alterar el catálogo por la puerta de atrás.

Todas las copias son superficiales (shallow). Copian las referencias, no los objetos:

Para una copia profunda hay que clonar elemento a elemento, y por eso la inmutabilidad de 03-07 es tan cómoda: si los objetos no cambian, la copia superficial es suficiente y no hay riesgo.

System.arraycopy es el más incómodo de los cuatro pero el más potente, porque copia sobre un array que ya existe, en la posición que quieras, y admite solapamiento con el mismo array de origen y destino. Es lo que usa ArrayList.remove(int) para tapar el hueco:

Es una operación O(n): hay que mover todos los elementos posteriores. Recuerda este detalle, porque es exactamente el coste que pagará ArrayList.remove(0) en 05-03 y el que LinkedList evita en 05-04.

En 03-03 usaste varargs para escribir métodos con un número variable de argumentos:

El secreto es que double... multas es exactamente double[] multas con azúcar sintáctico en la llamada: el compilador empaqueta los argumentos sueltos en un array antes de invocar el método.

De ahí se derivan tres reglas prácticas:

• Un parámetro varargs nunca es null si se llama con la sintaxis normal: sin argumentos llega un array de longitud 0. Puedes recorrerlo sin comprobar nada.
• Solo puede haber uno y debe ir el último: metodo(String etiqueta, double... valores) es válido; al revés, no.
• Puedes pasarle un array ya construido, lo que resulta muy útil para reenviar argumentos entre métodos.

Reunamos todo en el catálogo del proyecto, todavía en versión array, y ordenémoslo con los Comparator del módulo 4.

Y el uso, aplicando los comparadores de 04-06:

Funciona. Y contiene, escritas a mano, tres piezas que en la lección siguiente te dará el JDK hechas: el crecimiento automático, el desplazamiento al borrar y la distinción entre capacidad y tamaño ocupado.

Mira CatalogoArray con ojo crítico. Todo lo que tiene de más respecto a un List es infraestructura, no lógica de negocio:

Ninguna de esas limitaciones convierte al array en algo obsoleto. Un array sigue siendo la opción correcta cuando:

• El tamaño es conocido y fijo (una matriz 3×12, un tablero, un buffer de 4096 bytes).
• Trabajas con primitivos y el rendimiento importa: un int[] de un millón de elementos ocupa 4 MB; un List<Integer> puede ocupar cinco veces más por el autoboxing (05-02).
• Necesitas máxima velocidad de recorrido y la localidad de caché es determinante.
• Estás implementando una estructura de datos, como hacen ArrayList, HashMap y ArrayDeque por dentro.

Para todo lo demás —que en una aplicación de gestión es prácticamente todo— la respuesta es el Framework de Colecciones.

length con paréntesis. array.length() no compila. Es un atributo en arrays, un método en String y size() en colecciones. Ténlo en la cabeza como una tabla de tres filas.

Confundir capacidad con contenido. new Material[10] tiene length == 10 pero cero materiales. Si solo has rellenado tres celdas, recorrer las diez te dará siete NullPointerException. Lleva siempre un contador o recorta con Arrays.copyOf(array, n) antes de devolver.

Imprimir un array directamente. System.out.println(array) muestra [I@1b6d3586. Usa Arrays.toString(array) y, con más de una dimensión, Arrays.deepToString(array).

Comparar arrays con equals o ==. Ambos comparan referencias. Usa Arrays.equals y, con más dimensiones, Arrays.deepEquals.

Creer que el for-each modifica el array. for (int n : numeros) { n = 0; } no cambia nada: n es una copia. Si escribes en las celdas, usa for clásico. Si solo llamas a métodos del objeto, el for-each va perfecto.

Asignar en vez de copiar. Material[] copia = original; no copia; crea un alias. Usa original.clone() o Arrays.copyOf(original, original.length). Y recuerda que ambas son superficiales: los objetos apuntados se comparten.

Arrays.asList como si fuera una lista normal. Es una vista de tamaño fijo respaldada por el array: set sí, add/remove lanzan UnsupportedOperationException. Si necesitas modificarla, envuélvela en new ArrayList<>(...).

binarySearch sobre un array desordenado. Devuelve resultados sin sentido, sin ningún aviso. Ordena primero, con el mismo criterio con el que buscas. Y recuerda que el negativo devuelto es -(punto de inserción) - 1, no un simple "no está".

Olvidar poner a null la celda liberada al borrar. En eliminar, después del arraycopy, la última celda sigue apuntando al objeto que ya no forma parte del catálogo. Mientras el array viva, ese objeto no se puede recolectar: es una fuga de memoria silenciosa. ArrayList hace exactamente ese elementData[--size] = null por el mismo motivo.

Consejo de estilo: for-each por defecto. Si el bucle no necesita el índice, escribe for (Material m : catalogo). Es más corto, más claro e imposible de romper por los límites. Baja al for clásico solo cuando el índice sea realmente necesario.

Escribe una clase EstadisticasCatalogo con métodos estáticos que reciban un Material[]:

• int contarPorTipo(Material[] catalogo, String tipo): cuántos materiales de ese tipo hay.
• Material masCaro(Material[] catalogo): el de mayor tarifa diaria, o null si el array está vacío o es null.
• double tarifaMedia(Material[] catalogo): media de las tarifas diarias, 0.0 si no hay elementos.
• String[] titulos(Material[] catalogo): un array nuevo solo con los títulos.

Todos deben ignorar las celdas a null y usar for-each cuando sea posible.

Crea InformeMensual que gestione un int[][] prestamos de 3 filas (Libro, Revista, DVD) por 12 columnas (meses). Implementa:

• void registrar(int tipo, int mes): incrementa la celda correspondiente.
• int totalPorTipo(int tipo) y int totalPorMes(int mes).
• int mesMasActivo(): el índice del mes con más préstamos totales.
• String tabla(): una tabla formateada con printf que muestre filas, columnas y totales.

Escribe UtilCatalogo con métodos estáticos que apliquen la clase Arrays:

• Material[] anadir(Material[] catalogo, Material nuevo): devuelve un array nuevo con un elemento más (sin modificar el original).
• Material[] eliminarEn(Material[] catalogo, int indice): devuelve un array nuevo sin ese elemento.
• Material[] ordenadoPorTitulo(Material[] catalogo): devuelve una copia ordenada, dejando intacto el original.
• int buscarPorReferencia(Material[] catalogo, String referencia): usa Arrays.sort + Arrays.binarySearch sobre una copia y explica en un comentario por qué el índice devuelto no sirve para el array original.

Solución 1

Los cuatro métodos comparten el mismo esqueleto defensivo: comprobar null en el array, saltar los elementos null y devolver un valor neutro (0, null documentado, array vacío) cuando no hay datos. El detalle importante de titulos es el patrón "crear del tamaño máximo, contar, recortar": es la única forma de devolver un array del tamaño exacto cuando no sabes de antemano cuántos elementos habrá. Es también, exactamente, lo que hace ArrayList.toArray() por ti.

Solución 2

Observa la alternancia deliberada entre los dos bucles. totalPorTipo recorre una fila con for-each porque no necesita saber qué mes es cada valor. totalPorMes recorre las filas con for-each pero indexa la columna, porque el mes viene dado. Y mesMasActivo necesita el for clásico porque lo que devuelve es el índice. Cada bucle usa la herramienta que le corresponde.

Solución 3

Este ejercicio deja al descubierto lo incómodo que resulta el array para operaciones cotidianas. anadir construye un array entero para meter un elemento: O(n) cada vez. eliminarEn necesita dos arraycopy. Y buscarPorReferencia cuesta más que la búsqueda lineal que pretendía evitar, porque ordenar la copia es O(n log n) y luego hay que traducir el índice. La conclusión honesta es que para buscar por clave, el array es la estructura equivocada: lo correcto es un Map<String, Material>, con búsqueda O(1) y sin copias ni sondas. Es la lección 05-05.

Ya dominas la estructura sobre la que está construido todo lo demás. Sabes que un array es un bloque contiguo de memoria de tamaño fijo y tipo homogéneo, que es un objeto del heap aunque no tenga una clase visible, y que su contigüidad le da acceso O(1) por índice y una localidad de caché que ninguna otra estructura iguala. Distingues declarar, crear con new e inicializar con literal; conoces los valores por defecto y sabes que new Material[10] contiene diez null, no diez materiales; y tienes claro que length es un atributo, que los índices van de 0 a length - 1 y que salirse lanza ArrayIndexOutOfBoundsException —una excepción que el módulo 6 te enseñará a tratar.

Has aprendido por fin el for-each que quedó pospuesto en el módulo 2: su sintaxis for (Tipo e : origen), sus ventajas —menos código, imposible salirse de rango, misma forma para arrays y colecciones— y sus tres limitaciones exactas: no da el índice, no puede reasignar la celda (aunque sí modificar el objeto apuntado) y solo va hacia delante. Y tienes el criterio: for-each por defecto, for clásico cuando el índice sea imprescindible.

Sabes qué guarda realmente cada celda —valores en los arrays de primitivos, referencias en los de objetos—, con todo lo que se deriva: aliasing, null, peor localidad y la covarianza que puede lanzar ArrayStoreException en ejecución, el agujero que los genéricos de 10-01 vinieron a tapar. Manejas arrays multidimensionales entendiéndolos como arrays de arrays, incluidos los dentados con filas de longitudes distintas. Y tienes la clase Arrays en las manos: toString/deepToString para depurar, sort con y sin Comparator, binarySearch con sus dos advertencias, fill, copyOf, copyOfRange, equals/deepEquals frente al equals heredado que compara referencias, y asList con su trampa de vista de tamaño fijo. Sabes copiar de cuatro formas, y que todas son superficiales. Y sabes que un parámetro varargs es literalmente un array, nunca null, siempre el último.

BiblioTech tiene ahora un CatalogoArray que crece solo, borra tapando el hueco, devuelve copias defensivas y se ordena con cualquier Comparator del módulo 4. Funciona. Y su código es, en tres cuartas partes, infraestructura que no debería estar ahí: un contador n paralelo al length, un Arrays.copyOf para duplicar la capacidad, un System.arraycopy para desplazar, un null manual para no filtrar memoria. Nada de eso habla de bibliotecas ni de préstamos. Además, sigue sin poder garantizar que no haya ISBN duplicados sin un bucle O(n), y sin poder buscar por referencia en menos de O(n) ni agrupar préstamos por empleado sin bucles anidados O(n²).

En la lección siguiente, El Framework de Colecciones, verás el mapa completo de las estructuras que el JDK ya trae resueltas: la jerarquía Iterable → Collection → List/Set/Queue, el Map que va aparte y por qué, la regla de oro «declara por la interfaz, instancia la implementación», la tabla maestra que compara las diez implementaciones que usarás el resto de tu vida profesional, cómo funciona por dentro el for-each que acabas de aprender —con el Iterator que hay debajo y la temida ConcurrentModificationException— y un árbol de decisión para elegir la colección correcta a la primera. A partir de ahí, cada lección del módulo desarrollará una fila de esa tabla, y el CatalogoArray que acabas de escribir se quedará en la mitad de líneas.