El módulo 6 terminó con una promesa y una carencia. La carencia: nada se guarda al salir. Seis módulos de trabajo —el catálogo, los préstamos, las multas, las reservas, el historial— viven íntegramente en la memoria del proceso, y cuando el proceso termina, la memoria se libera y todo desaparece. La promesa: que este módulo lo resuelve.

Empezamos por la mitad más sencilla de la persistencia, que es leer. Leer es más sencillo que escribir por una razón práctica: si te equivocas leyendo, no destruyes nada. Si te equivocas escribiendo, puedes perder un fichero entero, y eso es exactamente lo que le va a pasar a alguien en la lección siguiente si no lee la tabla del parámetro append.

Esta lección cubre el modelo mental completo de qué es un fichero, cómo se localiza y cómo se lee texto de él con las dos APIs clásicas —FileReader y Scanner—, más el detalle que provoca más incidencias reales de todo el módulo: la codificación de caracteres. Al terminar, BiblioTech arrancará leyendo su catálogo de un fichero de texto, y si ese fichero no existe, arrancará igualmente con el catálogo vacío y dejando constancia en el registro, aplicando la degradación elegante que ya sabes diseñar.

Todo lo que se abra en esta lección se cierra con try-with-resources. Es la construcción de 06-06 y se da por completamente conocida: orden de cierre inverso, excepciones suprimidas, close() idempotente. No se vuelve a explicar; se usa siempre.

1. Por qué un programa necesita persistencia
2. Qué es un fichero: bytes en disco frente a objetos en memoria
3. El recorrido de un dato desde la aplicación hasta el disco
4. Rutas absolutas y relativas, y el directorio de trabajo
5. Separadores de ruta y portabilidad
6. La clase File: la API heredada que todavía te encontrarás
7. Lectura con FileReader: carácter a carácter
8. Lectura con Scanner sobre un fichero
9. useDelimiter y el parseo cómodo
10. Codificación de caracteres: UTF-8 y el desastre de las tildes
11. FileNotFoundException frente a IOException
12. Degradación elegante: BiblioTech arranca sin catálogo
13. Ficheros grandes y por qué no leerlo todo en memoria
14. Errores Comunes y Consejos
15. Ejercicios

La memoria de un proceso es volátil: existe mientras el proceso existe. Cuando main retorna, cuando el usuario cierra la ventana o cuando el sistema operativo mata el proceso, la JVM libera su memoria y todo lo que había en ella deja de existir. No hay nada que recuperar.

Esto no es un defecto de Java: es la naturaleza de la RAM. Un programa que solo trabaja en memoria es un programa sin memoria a largo plazo, y eso lo descalifica para casi cualquier uso real:

Fíjate en la última fila de la columna izquierda aplicada a BiblioTech: si la aplicación se cae con veinte préstamos activos, esos veinte préstamos no existieron nunca. La biblioteca real seguirá teniendo veinte libros fuera de la estantería, pero el sistema dirá que están todos disponibles. El sistema y el mundo dejan de coincidir, que es la peor cosa que le puede pasar a un sistema de gestión.

Persistir significa escribir el estado en un medio que sobrevive al proceso. En este módulo ese medio es el sistema de ficheros. En un sistema profesional grande suele ser una base de datos —lo verás con Hibernate en 11-03—, pero una base de datos es, por debajo, ficheros con mucha ingeniería encima. Todo empieza aquí.

Esta es la idea que hay que interiorizar antes de escribir una línea de código:

Un fichero es una secuencia de bytes con un nombre. Nada más. No tiene tipos, no tiene objetos, no tiene campos. Solo bytes numerados del 0 en adelante.

Compara los dos mundos:

Cuando tienes en memoria un Libro con título "Java Efectivo", autor "Bloch" e ISBN 978-0000000001, el objeto ocupa una zona de memoria con tres referencias a tres objetos String. En disco no puedes guardar referencias: una dirección de memoria no significa nada mañana ni en otra máquina. Tienes que serializar: convertir esa estructura en una secuencia de bytes que puedas volver a interpretar después. La forma más simple de hacerlo es escribir texto:

Esa línea es una decisión de diseño completa. Has elegido: un material por línea, campos separados por ;, orden fijo de campos, true/false para la disponibilidad. Cualquier programa que conozca esa convención puede leerla. Es exactamente lo que hace un fichero CSV, y lo formalizarás en 07-07.

La alternativa es dejar que Java haga la conversión por ti, con la serialización nativa de 07-05, que produce bytes ilegibles pero conserva la estructura completa de objetos. Cada opción tiene su precio, y lo verás.

Un matiz importante sobre el vocabulario: se habla de ficheros de texto y ficheros binarios, pero esa distinción no existe en el disco. Todos los ficheros son binarios. Un "fichero de texto" es simplemente un fichero cuyos bytes, interpretados con una determinada codificación, producen caracteres legibles. Si abres un .jpg con un editor de texto, verás basura: no porque el fichero sea distinto, sino porque estás aplicando la interpretación equivocada. Volveremos a esto en el apartado 10 y, a fondo, en 07-03.

Entre tu String y el plato del disco hay más capas de las que parece. Conocerlas explica por qué la E/S es lenta, por qué existe el búfer y por qué un close() puede fallar.

Los puntos que importan de ese recorrido:

• La frontera cara es la llamada al sistema (recuadro naranja). Cada read obliga a pasar del código de tu aplicación al núcleo del sistema operativo y volver. Ese cambio de contexto cuesta órdenes de magnitud más que ejecutar unas instrucciones en memoria. Si haces una llamada al sistema por cada carácter, el coste es demoledor: es exactamente lo que ocurre con FileReader sin búfer, y lo medirás en el apartado 7.
• La decodificación es un paso real (recuadro azul claro del medio). Los bytes que llegan del disco no son caracteres. Alguien tiene que decidir qué byte o grupo de bytes forma qué carácter, y ese alguien es el charset. Si nadie lo especifica, se usa uno por defecto, y ahí empiezan los problemas del apartado 10.
• El sistema operativo ya tiene su propia caché (la page cache). Por eso leer dos veces el mismo fichero pequeño es mucho más rápido la segunda vez: la segunda no llega al disco. Esto también explica por qué medir rendimiento de E/S es traicionero.
• Escribir no significa "está en el disco". Cuando escribes, el dato pasa a búferes intermedios. Hasta que no se vacían, un corte de corriente lo pierde. Es el tema central de 07-02.

Quédate con la regla que gobierna todo el módulo: cuantas menos llamadas al sistema, mejor. Todo el diseño de la E/S de Java —los búferes, los bloques, transferTo— existe para reducir ese número.

Para leer un fichero hay que localizarlo, y aquí aparece el primer tropiezo clásico: "a mí me funcionaba y en el servidor dice que no encuentra el fichero".

Una ruta absoluta parte de la raíz del sistema de ficheros y es autosuficiente:

Una ruta relativa no parte de la raíz, sino del directorio de trabajo actual del proceso:

La pregunta clave es: ¿relativa a qué? Y la respuesta es la que sorprende a todo el mundo: relativa al directorio desde el que se lanzó la JVM, no al directorio donde está el .class ni al del proyecto. Ese directorio está en la propiedad de sistema user.dir:

Ejecuta ese programa desde dos sitios distintos y verás el problema en directo:

El mismo programa, el mismo fichero en disco, dos resultados distintos. Esto es lo que ocurre cuando funciona en el IDE (que lanza desde la raíz del proyecto) y falla al ejecutarlo con un script (que lanza desde otro sitio).

Cómo se trata esto profesionalmente:

Y un consejo que ahorra mucho tiempo: cuando un fichero "no existe", imprime siempre la ruta absoluta, nunca la que te pasaron. El mensaje No se encuentra 'datos/catalogo.txt' no te dice nada; No se encuentra '/home/marta/bibliotech/target/classes/datos/catalogo.txt' te resuelve el problema en tres segundos. Esta es una aplicación directa de la lección 06-04: una excepción debe transportar los datos que quien la lee necesita para decidir.

Windows usa \ como separador de directorios; Linux, macOS y prácticamente todo lo demás usan /. Java ofrece dos constantes para no fijarlo en el código:

Distingue las dos constantes, que se confunden con frecuencia:

Ahora bien, la buena noticia práctica: Windows acepta / en casi todas las APIs de Java. new File("datos/catalogo.txt") funciona en Windows. Por eso, en la práctica:

• Para literales cortos en el código, escribe / y no te compliques: es legible y funciona en todas partes.
• Para componer rutas a partir de trozos, no concatenes cadenas: usa new File(padre, hijo) o, mejor todavía, Path.resolve() de NIO.2, que verás en 07-06 y es la forma moderna y correcta.
• Nunca escribas "C:\\datos\\catalogo.txt" en el código. Además de no ser portable, ese doble backslash es una fuente inagotable de erratas.

java.io.File es de Java 1.0. Representa una ruta, no un fichero abierto: puedes crear un File que apunte a algo inexistente sin que pase nada.

Los métodos que más se usan:

Y aquí está el gran defecto de esta API, el que motivó su sustitución:

Ese false mudo es exactamente el antipatrón que el módulo 6 dedicó siete lecciones a erradicar: comunicar un fallo sin decir cuál. La API moderna, NIO.2 (java.nio.file.Path y Files, lección 07-06), lanza excepciones específicas —NoSuchFileException, AccessDeniedException, DirectoryNotEmptyException— en lugar de devolver boolean.

Entonces, ¿por qué aprendemos File? Por tres motivos muy prácticos. Primero, porque hay millones de líneas de código escritas con ella y las vas a leer. Segundo, porque muchas APIs todavía piden un File como parámetro. Y tercero, porque la conversión entre ambos mundos es trivial: file.toPath() y path.toFile(). Usa NIO.2 en el código nuevo; entiende File para leer el antiguo.

FileReader es la clase más elemental para leer texto de un fichero. Su método fundamental es read(), y su contrato tiene un detalle que hay que entender bien:

Devuelve un int, no un char. ¿Por qué? Porque necesita un valor extra que no sea un carácter válido para señalar el fin de fichero, y ese valor es -1. Los caracteres válidos van de 0 a 65535; -1 no colisiona con ninguno. Si el método devolviera char, no habría forma de distinguir "he leído el carácter 0" de "se acabó".

Desmenucemos el bucle, porque su forma es idiomática y la verás por todas partes:

1. lector.read() lee el siguiente carácter y avanza la posición.
2. codigo = ... guarda el resultado en la variable. En Java, una asignación es una expresión cuyo valor es el asignado; por eso puede usarse dentro de la condición.
3. Los paréntesis externos son obligatorios: sin ellos, codigo = lector.read() != -1 intentaría asignar un boolean a un int y no compilaría.
4. La comparación decide si seguir.

Y ahora, el problema. Este código es correcto pero lento, y conviene entender exactamente cuánto:

Con un fichero de 5 MB, en una máquina de escritorio corriente, los órdenes de magnitud son estos (cifras ilustrativas, no una medición formal):

Dos órdenes de magnitud de diferencia, y la causa es exactamente la del apartado 3: cada read() sin búfer se traduce en una petición al sistema operativo. Cinco millones de cruces de frontera para leer cinco megabytes.

La solución intermedia, sin salir todavía de FileReader, es leer por bloques con la sobrecarga que acepta un array:

Dos detalles críticos de ese código, y los dos son fuente de errores reales:

• read(char[]) devuelve el número de elementos leídos, que puede ser menor que el tamaño del array aunque el fichero no se haya terminado. Nunca supongas que llena el búfer.
• Hay que usar append(bloque, 0, leidos), no append(bloque). Si usas la versión sin límites, en la última vuelta añadirás la basura que quedó en el array de la vuelta anterior. Es un fallo que solo se manifiesta al final del fichero y con contenido aparentemente aleatorio.

La forma definitiva de resolver esto —envolver el FileReader en un BufferedReader que gestiona el bloque por ti— es el tema de 07-04. Aquí queda claro el porqué; allí verás el cómo con todo el detalle.

Ya conoces Scanner del módulo 1, leyendo de System.in. La misma clase lee de un fichero: solo cambia lo que le pasas al constructor.

El par hasNextLine() / nextLine() es el patrón canónico y merece un aviso:

Comprueba siempre con hasNextLine() antes de llamar a nextLine(). Si llamas a nextLine() sin quedar líneas, lanza NoSuchElementException, que es no comprobada: el compilador no te avisa y explota en ejecución. Es el mismo contrato de Iterator que viste en 05-02.

Scanner no se queda en líneas: sabe parsear tipos, y ahí está su comodidad. Supón este fichero de préstamos de BiblioTech:

Se lee así, campo a campo, sin partir cadenas a mano:

Cuidado con dos comportamientos de Scanner que causan sorpresas:

• nextDouble() depende de la configuración regional. Con el idioma español, el separador decimal es la coma, así que 0.25 puede fallar con InputMismatchException mientras que 0,25 funciona. Es un fallo que aparece solo en algunas máquinas y desconcierta. La solución es fijar la configuración explícitamente:

Este mismo problema, aplicado a los ficheros CSV que se abren en una hoja de cálculo española, reaparece en 07-07.

• nextInt() no consume el salto de línea. Si mezclas nextInt() con nextLine(), el nextLine() devolverá la cadena vacía que queda hasta el final de la línea actual. Es la trampa que ya viste con la consola en el módulo 1, y aquí es idéntica.

Comparación honesta de las dos APIs vistas hasta ahora:

Para un fichero de configuración de veinte líneas, Scanner es cómodo y su lentitud es irrelevante. Para el fichero de catálogo de diez mil materiales, la respuesta correcta es BufferedReader, y la verás en 07-04.

Por defecto, Scanner separa por espacios en blanco. useDelimiter cambia ese criterio a cualquier expresión regular, lo que permite leer ficheros con separadores propios sin partir cadenas a mano.

Con este fichero de catálogo:

Se lee así:

Delimitadores útiles:

Ese último truco tiene su gracia para ficheros muy pequeños:

Funciona, pero es un apaño. Desde Java 11 existe Files.readString(Path), que hace lo mismo de forma explícita y correcta, y lo verás en 07-06. Reconoce el truco cuando lo leas en código ajeno; no lo escribas tú.

Y una advertencia que hay que dar ya, aunque se desarrolle en 07-07: partir un CSV por ; o por , es correcto solo mientras ningún campo contenga el separador. En cuanto aparezca un título como "Java: el lenguaje, la máquina y el ecosistema" dentro de comillas, este código produce campos mal alineados en silencio. La lección 07-07 implementa un lector CSV que sí lo hace bien.

Este apartado es el más importante de la lección. La mayoría de los fallos de E/S que verás en tu carrera profesional no son fallos de lógica: son fallos de codificación.

Un fichero contiene bytes. Un String contiene caracteres. Convertir de uno a otro requiere una tabla de correspondencias, y esa tabla es el charset o codificación.

• ASCII (1963): 128 caracteres, un byte cada uno. Sin ñ, sin á, sin €.
• ISO-8859-1 (Latin-1): 256 caracteres, un byte cada uno. Tiene ñ y vocales acentuadas. No tiene € ni nada no europeo occidental.
• Windows-1252: variante de la anterior, la de Windows en Europa occidental. Casi igual pero no exactamente, lo que genera fallos sutiles.
• UTF-8 (1993): cubre todo Unicode con longitud variable de 1 a 4 bytes. ASCII es un subconjunto exacto suyo. Es el estándar de facto de la web y del intercambio de datos.

Cuánto ocupa cada carácter en UTF-8:

Consecuencia directa que sorprende a mucha gente: en UTF-8, el número de caracteres de un texto no es el número de bytes del fichero. "Diseño" son 6 caracteres y 7 bytes. Por eso File.length() (bytes) no te dice cuántos caracteres hay.

Escribes "Patrones de Diseño" en UTF-8 y lo lees como ISO-8859-1. Los dos bytes de la ñ (0xC3 0xB1) se interpretan como dos caracteres independientes:

Al revés, escribes en ISO-8859-1 y lees en UTF-8. El byte 0xF1 de la ñ no forma una secuencia UTF-8 válida, y el decodificador lo sustituye por el carácter de reemplazo:

Ese ñ y ese � son los dos síntomas que hay que aprender a reconocer al instante. Cuando los veas, no busques el fallo en tu lógica: es codificación.

Y hay algo peor que la fealdad. Fíjate en este caso:

Los datos siguen mal después de leerlos. Se guardarán mal, se compararán mal y se mostrarán mal. La corrupción se propaga.

Hasta Java 17 incluido, cuando no especificas charset, FileReader y FileWriter usan la codificación por defecto de la plataforma, que depende del sistema operativo y de la configuración regional:

Esto significa que el mismo programa leyendo el mismo fichero produce resultados distintos en máquinas distintas. Es la causa del clásico "en mi portátil se ve bien y en el servidor sale con interrogantes".

Java 18 (JEP 400) cambió el valor por defecto de file.encoding a UTF-8 en todas las plataformas, lo cual es una gran mejora. Pero:

• Si trabajas con Java 17 —la versión de referencia de este curso y la más usada en producción— sigues teniendo el comportamiento antiguo.
• Aunque tu proyecto sea Java 21, el código que especifica el charset es autoexplicativo y no depende de una propiedad que alguien pueda cambiar con -Dfile.encoding.

Regla profesional, sin excepciones: especifica siempre el charset explícitamente en toda operación de texto. No cuesta nada y elimina una categoría entera de fallos.

Desde Java 11, FileReader acepta un Charset en el constructor:

En versiones anteriores —y sigue siendo la forma más general, la que verás en 07-03— se usa el puente InputStreamReader:

Y Scanner también lo acepta:

Las constantes disponibles en java.nio.charset.StandardCharsets, garantizadas en toda JVM:

Usa las constantes, no las cadenas. new FileReader(ruta, StandardCharsets.UTF_8) no puede fallar; la versión que acepta el nombre como cadena lanza UnsupportedEncodingException si escribes "UTF8", "utf-8 " con un espacio o cualquier otra errata. Es un error de compilación convertido en error de ejecución sin ninguna ventaja.

La E/S es el territorio natural de las excepciones comprobadas del módulo 6, y por un motivo que ahora resulta evidente: el fichero es del mundo exterior. Puede no existir, puede haber cambiado de permisos, el disco puede llenarse, alguien puede desconectar la unidad de red. Nada de eso es un fallo de tu programa, y todo es previsible.

La jerarquía relevante:

Qué significa cada una en la práctica:

Nota engañosa sobre el nombre: FileNotFoundException no significa solo "no existe". También se lanza si la ruta apunta a un directorio o si el fichero existe pero no tienes permiso de lectura. Por eso el mensaje del sistema operativo es tan valioso y nunca debes descartarlo.

El orden de los catch sigue la regla de 06-02, de lo específico a lo general:

Vamos a juntarlo todo con la primera pieza real del módulo. CargadorCatalogo lee un fichero de texto y construye materiales, y —esto es lo importante— si el fichero no existe, la aplicación arranca igualmente con el catálogo vacío.

Este es exactamente el criterio de 06-07 para distinguir lo recuperable de lo irrecuperable: degrada cuando el servicio reducido siga siendo correcto. Una biblioteca sin materiales es una biblioteca vacía, que es un estado perfectamente válido y en el que se pueden dar de alta materiales. No hay nada incorrecto en ello. Muy distinto sería arrancar sin conocer la tarifa de las multas: ahí no se puede degradar, porque cobraríamos importes falsos.

El formato del fichero:

Y el cargador:

Y el arranque de la aplicación queda así:

Las tres decisiones de diseño que conviene señalar:

1. La ruta llega por argumento, con un valor por defecto. Es la estrategia recomendada del apartado 4: quien ejecuta decide dónde están los datos.
2. cargar() nunca devuelve null. Devuelve un Catalogo vacío si no hay fichero. Es la regla que 06-07 estableció: el null no es una forma de comunicar nada.
3. Una línea mala no aborta el fichero. Se descarta, se cuenta y se registra. Que un catálogo de diez mil líneas no se cargue porque la línea 4 200 tiene un año mal escrito sería una política pésima. Esto es el "objeto resultado" de 06-07 aplicado a la importación, y en 07-04 se convertirá en un informe completo.

Cerramos con una advertencia de dimensionamiento. Es tentador escribir esto:

Y para un fichero de configuración de 2 KB es perfectamente razonable. Pero para el histórico de préstamos de tres años, no:

Por qué el factor de dos: internamente un String de Java 9 en adelante guarda un byte por carácter cuando todo el texto es Latin-1 y dos bytes por carácter en cuanto aparece un carácter fuera de ese rango. Un solo emoji o un carácter cirílico en un fichero de 2 GB duplica la memoria del String completo. Y además necesitas el StringBuilder intermedio mientras lo construyes, así que en el pico llegas a tener el contenido dos veces.

Un OutOfMemoryError es un Error, no una Exception: no se captura, no se recupera y tumba el proceso, con la salvedad de la frontera de main que viste en 06-07.

La alternativa correcta es procesar en flujo (streaming): leer una línea, procesarla, olvidarla, leer la siguiente. La memoria usada es la de una línea, no la del fichero, y el consumo es constante aunque el fichero tenga 50 GB:

La regla práctica:

Carga el fichero entero en memoria solo si conoces su tamaño máximo y es pequeño. Configuración, plantillas, ficheros de pocos KB: adelante. Datos, registros, exportaciones, cualquier cosa que crezca con el uso: procesa en flujo.

Esa es exactamente la razón de ser de BufferedReader, que es la lección 07-04.

• Usar rutas relativas y no saber respecto a qué. El clásico "funciona en el IDE y falla en producción". Imprime System.getProperty("user.dir") en cuanto tengas dudas y pasa las rutas por parámetro.
• Informar del error con la ruta relativa. No se encuentra 'datos/catalogo.txt' no sirve para nada. Registra siempre getAbsolutePath().
• No especificar el charset. El error más caro del módulo a largo plazo, porque no falla: corrompe en silencio. StandardCharsets.UTF_8, siempre, en toda operación de texto.
• Confundir ñ con ?. ñ significa que escribiste UTF-8 y leíste Latin-1. ? o � significa lo contrario. Reconocer el síntoma te ahorra media hora cada vez.
• Usar cadenas en lugar de constantes de charset. "UTF8" compila y explota en ejecución. StandardCharsets.UTF_8 no puede escribirse mal.
• Declarar char c = lector.read(). No compila, y por un buen motivo: hace falta el -1 para el fin de fichero, que no cabe en un char.
• Olvidar los paréntesis en while ((c = lector.read()) != -1). Sin ellos no compila. Con ellos, es el bucle idiomático que verás siempre.
• Usar append(bloque) en lugar de append(bloque, 0, leidos). Añade basura de la vuelta anterior en la última lectura. Falla solo al final del fichero, que es lo que lo hace difícil de diagnosticar.
• Llamar a nextLine() sin comprobar hasNextLine(). NoSuchElementException, no comprobada, en ejecución.
• Mezclar nextInt() y nextLine() sin consumir el salto de línea. La misma trampa del módulo 1, idéntica sobre ficheros.
• Confiar en nextDouble() sin fijar el Locale. En una máquina con configuración española, 0.25 puede fallar. sc.useLocale(Locale.ROOT).
• Leer carácter a carácter un fichero grande. Correcto y cien veces más lento. Bloques o BufferedReader (07-04).
• Cargar en un String un fichero de tamaño desconocido. OutOfMemoryError, que no se captura. Procesa en flujo.
• Interpretar length() == 0 como "no existe". Un fichero vacío da lo mismo. Usa exists().
• Ignorar que listFiles() puede devolver null. NullPointerException en el for. NIO.2 lo resuelve (07-06).
• Consejo: escribe una única clase que sepa leer cada tipo de fichero. Si tienes new FileReader(...) repartido por veinte clases, cambiar el charset o el formato será un rastreo. Concentra la E/S en la capa que le corresponde, como hace CargadorCatalogo.
• Consejo: prueba siempre con un fichero que contenga ñ, á y €. Un fichero de prueba solo con ASCII te ocultará todos los fallos de codificación hasta que llegue a producción.
• Consejo: prueba también con el fichero ausente y con el fichero vacío. Son los dos casos que más se olvidan y los dos que más ocurren, sobre todo el primer día de vida del sistema.

Escribe una clase DiagnosticoRuta con un método public static void diagnosticar(String ruta) que imprima un informe completo y útil sobre una ruta, pensado para que alguien pueda resolver un problema con él:

1. La ruta tal como se dio y su forma absoluta.
2. El directorio de trabajo actual.
3. Si existe; y si no existe, si existe su directorio padre (para distinguir "el fichero falta" de "el directorio no es ese").
4. Si existe: si es fichero o directorio, si es legible, su tamaño y el número de líneas.
5. Un diagnóstico final en una frase con la causa más probable.

Pruébalo con una ruta correcta, una inexistente y un directorio.

Escribe DetectorCodificacion con un método public static void comparar(String ruta) que lea el mismo fichero tres veces —como UTF-8, como ISO-8859-1 y como US-ASCII— y muestre las tres primeras líneas de cada lectura, para ver el efecto sobre las tildes y las eñes.

Después, añade public static boolean pareceUtf8(String ruta), que devuelva true si el fichero se decodifica sin ningún carácter de reemplazo (\uFFFD) al leerlo como UTF-8. Explica en un comentario por qué esa comprobación detecta "esto no es UTF-8" pero no puede detectar "esto es Latin-1 leído como UTF-8 al revés".

Prepara un fichero de prueba con Patrones de Diseño, Refactorización y Año 2018.

Amplía la idea de CargadorCatalogo a los empleados. Dado un fichero como este:

Escribe CargadorEmpleados con:

1. public ResultadoCarga cargar(), que devuelva un objeto resultado (idea de 06-07) con la lista de empleados cargados y la lista de errores, en lugar de lanzar en el primer fallo.
2. Validación de cada línea: exactamente 3 campos, identificador con formato E-NNN, nombre no vacío y número de préstamos entre 0 y Empleado.MAX_PRESTAMOS_SIMULTANEOS.
3. Degradación si el fichero no existe: resultado vacío con un aviso, sin excepción.
4. Charset explícito y try-with-resources.
5. Un main de demostración que imprima el informe con printf.

Añade al fichero de prueba una línea con dos campos, una con un identificador X-999 y una con 9 préstamos, para comprobar que las tres se descartan con su motivo y las buenas se cargan.

Solución 1

Lo que enseña este ejercicio: la diferencia entre detectar un fallo y explicarlo. Los cinco casos de concluir corresponden a cinco causas distintas que la API resume todas en un exists() a false. Distinguirlas es lo que convierte un mensaje de error en una solución. Fíjate también en el comentario sobre TOCTOU: entre comprobar exists() y abrir el fichero puede pasar cualquier cosa, así que la comprobación previa no sustituye al catch.

Solución 2

Con un fichero de prueba guardado en UTF-8 que contenga Patrones de Diseño, Refactorización y Año 2018, la salida es:

La conclusión práctica es la del comentario: la detección de codificación es fundamentalmente imposible en el caso general. Los editores de texto la adivinan con heurísticas y a veces se equivocan. Por eso ninguna cantidad de listeza en el código sustituye a la regla simple: especifica siempre el charset, al leer y al escribir.

Solución 3

Con este fichero de prueba:

La salida es:

Las tres decisiones que merece la pena señalar:

1. El objeto resultado en lugar de una excepción por línea. Quien importa un fichero quiere ver todos los problemas de una vez para corregirlos y volver a intentarlo, no descubrirlos de uno en uno. Es exactamente el caso de uso que 06-07 planteó para el objeto resultado.
2. split(SEPARADOR, -1). Sin ese -1, split descarta los campos vacíos finales, así que E-001;; daría 1 campo en vez de 3 y el mensaje de error sería incorrecto. Es una trampa clásica que reaparecerá en 07-07.
3. El fichero ausente no es un error de línea. Se marca aparte, porque son dos situaciones distintas: "no hay datos" y "hay datos mal escritos". Confundirlas produce informes inútiles.

Has puesto los cimientos de la persistencia de BiblioTech.

Entiendes qué es un fichero de verdad: una secuencia de bytes con un nombre, sin tipos ni estructura, frente a un objeto en memoria con campos y referencias. Sabes que pasar de uno a otro exige una decisión de formato explícita —un material por línea, campos separados por ;— y que esa decisión es el germen del CSV de 07-07. Y conoces el recorrido completo del dato hasta el disco, con la conclusión que gobierna todo el módulo: la llamada al sistema es la operación cara, y todo el diseño de la E/S existe para reducir su número.

Sabes localizar un fichero: rutas absolutas y relativas, el papel de user.dir como origen de las relativas, y por qué el mismo programa "no encuentra" el mismo fichero según desde dónde se lance. Tienes las cinco estrategias profesionales para no depender de eso, con la recomendación de pasar la ruta por parámetro, y la regla de registrar siempre la ruta absoluta en los mensajes de error. Conoces File.separator frente a File.pathSeparator y por qué es mejor componer rutas que concatenar cadenas.

Conoces java.io.File —exists, isFile, canRead, length, getAbsolutePath— y, sobre todo, el defecto que la condenó: los boolean mudos que dicen que algo falló sin decir por qué, exactamente el antipatrón que el módulo 6 erradicó. Sabes que 07-06 la sustituye por Path y Files, y que la conversión entre ambas es un toPath().

Sabes leer con FileReader carácter a carácter, con el int de retorno y el -1 de fin de fichero, y por qué ese bucle es dos órdenes de magnitud más lento de lo necesario. Conoces la lectura por bloques con read(char[]) y sus dos trampas: el valor de retorno que puede ser menor que el array, y el append(bloque, 0, leidos) que evita arrastrar basura. Y sabes leer con Scanner sobre fichero, con hasNextLine/nextLine, el parseo de tipos, useDelimiter con expresiones regulares, y sus dos sorpresas: el Locale que cambia el separador decimal y el nextInt() que no consume el salto de línea.

Y tienes el apartado que más incidencias reales evita: la codificación. Sabes qué es UTF-8, por qué ñ ocupa dos bytes, qué significa exactamente ver ñ y qué significa ver �, por qué la codificación por defecto de la plataforma es una bomba de relojería entre máquinas, qué cambió Java 18 y por qué eso no te exime de especificarla. Y sabes que detectar la codificación es imposible en el caso general, lo que convierte la regla en absoluta: StandardCharsets.UTF_8, explícito, siempre.

BiblioTech ya lee. CargadorCatalogo construye el catálogo desde un fichero de texto, descarta las líneas mal formadas contándolas y registrándolas en lugar de abortar la carga entera, traduce NumberFormatException y ReferenciaDuplicadaException a descartes con contexto, y —lo más importante— degrada elegantemente: si no hay fichero de catálogo, arranca con el catálogo vacío y un WARNING, porque una biblioteca vacía es un estado correcto. Es la política de errores de 06-07 aplicada a la E/S desde la primera línea de código.

Queda la mitad que falta, y es la que da miedo. Leer es seguro; escribir destruye. En la lección 07-02, Escritura de Archivos, verás FileWriter y el parámetro append que decide entre añadir al final y borrar el fichero entero, que es el error más caro de todo el módulo; PrintWriter con el printf que ya usas desde el módulo 1; el búfer y el vaciado, y por qué lo que has escrito puede no estar en el disco hasta que cierres; el patrón de escritura atómica —escribir a un temporal y renombrar— que impide dejar un fichero a medias cuando algo falla a mitad, hermano directo de la compensación en finally que ya sabes escribir; y el separador de línea del sistema, con el motivo por el que \n no siempre basta. Al terminarla, ExportadorCatalogo dejará de ser una clase que sabe cerrarse pero no escribir, y BiblioTech guardará por primera vez lo que ha hecho.