ant

Ir sumando trozos a una cadena con += dentro de un bucle es de esos errores que no se notan con diez elementos y que, con cien mil, dejan un proceso parado varios segundos. Lo medimos, y vemos de paso que la versión clásica tiene además un fallo con las listas vacías.

El código del problema

record Persona(String nombre) {}

String conMas(List<Persona> personas) {
    String s = "";
    for (Persona p : personas) s += ", " + p.nombre();
    return s.substring(2);
}

Funciona, y con tres nombres devuelve Ana, Luis, Marta. El problema es que las cadenas de Java no se pueden modificar: cada += crea una cadena nueva y copia en ella todo lo que ya había más el trozo nuevo. En la vuelta mil se copian los 999 nombres anteriores; en la diez mil, los 9,999. El trabajo total crece con el cuadrado del número de elementos.

Medido

Comparamos esa función con la versión de StringBuilder que hay más abajo, tomando la mejor de cinco ejecuciones para cada tamaño:

long medir(java.util.function.Supplier<String> f) {
    long mejor = Long.MAX_VALUE;
    for (int r = 0; r < 5; r++) {
        long t = System.nanoTime(); f.get(); mejor = Math.min(mejor, System.nanoTime() - t);
    }
    return mejor;
}

java Medir.javapersonas        +=   StringBuilder
     10,000       70 ms       1.18 ms
     20,000      260 ms       0.47 ms
     40,000     1001 ms       0.62 ms
     80,000     4338 ms       0.91 ms

Los milisegundos dependen de la máquina; lo que hay que mirar es cómo crecen. Cada vez que se dobla la lista, += tarda unas cuatro veces más: 70, 260, 1001, 4338. Es la firma de un algoritmo cuadrático. StringBuilder se queda en torno al milisegundo en todos los casos (a esas escalas el ruido de la medida pesa más que el trabajo, y por eso no crece de forma ordenada).

Y además falla con la lista vacía

El substring(2) del final quita la coma y el espacio que sobran al principio. Pero si la lista está vacía, no hay nada que quitar:

conMas(List.of())  —  salida recortadaException in thread "main" java.lang.StringIndexOutOfBoundsException: Range [2, 0) out of bounds for length 0
	...
	at Concatenar.conMas(Concatenar.java:9)

Es el típico arreglo que funciona en todas las pruebas hasta el día en que llega una lista vacía.

La versión con StringBuilder

String conBuilder(List<Persona> personas) {
    var sb = new StringBuilder();
    for (Persona p : personas) {
        if (sb.length() > 0) sb.append(", ");
        sb.append(p.nombre());
    }
    return sb.toString();
}

StringBuilder sí se puede modificar: va añadiendo al final de un búfer que crece cuando hace falta, así que cada nombre se copia una sola vez. Y la coma se pone antes de cada elemento salvo el primero, con lo que no hay nada que quitar al final y la lista vacía devuelve una cadena vacía.

Sin escribir el bucle

Para el caso más común, unir elementos con un separador, ni siquiera hace falta el StringBuilder:

IO.println(String.join(", ", tres.stream().map(Persona::nombre).toList()));
IO.println(tres.stream().map(Persona::nombre).collect(Collectors.joining(", ", "[", "]")));
var sj = new StringJoiner(" | ");
for (Persona p : tres) sj.add(p.nombre());
IO.println(sj);

salidaAna, Luis, Marta
[Ana, Luis, Marta]
Ana | Luis | Marta

¿Y el + fuera de los bucles?

No hay que tenerle miedo. Una expresión como "Hola, " + nombre + ". Tienes " + n + " mensajes" se resuelve en una sola operación: desde Java 9 el compilador la traduce a una llamada especializada que calcula el tamaño final y copia cada parte una vez. Cambiarla por un StringBuilder escrito a mano solo la hace más difícil de leer. El problema es acumular en un bucle, no el operador.

Entrada publicada en 2011 y revisada en octubre de 2026. Todo el código se compiló y se ejecutó con Java 25 LTS en un contenedor limpio; las salidas están copiadas de esa ejecución.

FileUtils, de Apache Commons IO, resume en una línea tareas con archivos que con java.io llevaban diez. Este es el ejemplo de siempre, leer un archivo y listar los de ciertas extensiones, puesto al día. Y al lado, la versión con java.nio, que hoy hace casi lo mismo sin añadir nada.

La dependencia

<dependency>
    <groupId>commons-io</groupId>
    <artifactId>commons-io</artifactId>
    <version>2.22.0</version>
</dependency>

Es la última versión publicada en Maven Central. Si no usas Maven, basta con descargar el .jar y añadirlo al classpath.

El ejemplo

import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.Collection;

public class Prueba {
    public static void main(String[] args) throws IOException {
        File archivo = new File("ejemplo.txt");
        String contenido = FileUtils.readFileToString(archivo, StandardCharsets.UTF_8);
        System.out.println("contenido: " + contenido.strip());

        String[] extensiones = {"xml", "java", "dat"};
        Collection<File> archivos = FileUtils.listFiles(new File("proy"), extensiones, true);
        for (File f : archivos) {
            System.out.println("> " + f.getPath());
        }
    }
}

Lo probamos con un ejemplo.txt de una línea y una carpeta proy con seis archivos, de los que solo tres tienen las extensiones que buscamos:

javac -cp commons-io-2.22.0.jar Prueba.java
java -cp .:commons-io-2.22.0.jar Prueba

salidacontenido: Hola desde decodigo.com
> proy/pom.xml
> proy/src/main/java/ejemplo/App.java
> proy/datos/clientes.dat

Encontró el .xml, el .java y el .dat, en cualquier nivel de subcarpetas, y dejó fuera el .txt, el .md y el .class. El orden es el que devuelve el sistema de archivos, que no tiene por qué ser alfabético.

Lo que cambió desde la versión de 2011

El código original llamaba a readFileToString(archivo) sin indicar la codificación. Ese método está obsoleto:

javac -Xlint:deprecationVieja.java:6: warning: [deprecation] readFileToString(File) in FileUtils has been deprecated
        System.out.println(FileUtils.readFileToString(new File("ejemplo.txt")).strip());
                                    ^
1 warning

Sin codificación, el archivo se lee con la del sistema, y el mismo programa puede leer bien los acentos en un equipo y mal en otro. Por eso hay que pasar siempre StandardCharsets.UTF_8 (o la que tenga el archivo). El otro cambio es de estilo: la lista ahora es una Collection<File> con tipo, y se recorre con un for normal, sin Iterator ni conversiones.

Lo mismo sin dependencias

import java.io.IOException;
import java.nio.file.*;
import java.util.Set;
import java.util.stream.Stream;

void main() throws IOException {
    String contenido = Files.readString(Path.of("ejemplo.txt"));
    IO.println("contenido: " + contenido.strip());

    Set<String> extensiones = Set.of("xml", "java", "dat");
    try (Stream<Path> rutas = Files.walk(Path.of("proy"))) {
        rutas.filter(Files::isRegularFile)
             .filter(p -> {
                 String n = p.getFileName().toString();
                 int punto = n.lastIndexOf('.');
                 return punto > 0 && extensiones.contains(n.substring(punto + 1));
             })
             .sorted()
             .forEach(p -> IO.println("> " + p));
    }
}

java SinDependencias.javacontenido: Hola desde decodigo.com
> proy/datos/clientes.dat
> proy/pom.xml
> proy/src/main/java/ejemplo/App.java

Files.readString lee en UTF-8 por omisión, y Files.walk recorre el árbol. Filtrar por extensión lleva unas líneas más que con FileUtils, pero no hace falta ningún .jar. Aquí además las ordenamos con sorted(). El try con recursos es necesario, porque Files.walk deja abiertos los directorios hasta que se cierra el stream.

Para leer y escribir, java.nio basta. Commons IO sigue ahorrando trabajo en las operaciones con directorios enteros, como copiarlos o borrarlos. Las vemos, con sus salidas, en FileUtils de Commons IO.

Entrada publicada en 2011 y revisada en octubre de 2026. Todo el código se compiló y se ejecutó con Java 25 LTS en un contenedor limpio con Commons IO 2.22.0; las salidas están copiadas de esa ejecución.