Context​

I was simplifying some stream pipelines and swapped collect(Collectors.toList()) for the newer Stream.toList(). Tests started failing with UnsupportedOperationException. Not obvious why at first.

The discovery​

Stream.toList() returns an unmodifiable list. Collectors.toList() returns a regular mutable ArrayList.

// Collectors.toList() — mutable, you can add/remove after
List<String> mutable = stream.collect(Collectors.toList());
mutable.add("extra"); // fine

// Stream.toList() — unmodifiable
List<String> immutable = stream.toList();
immutable.add("extra"); // throws UnsupportedOperationException

Collectors.toUnmodifiableList() existed before Java 16 and gives the same behaviour as Stream.toList() — so the new method is really a shorthand for the unmodifiable version, not the mutable one.

Why it matters​

If you're collecting into a list you then mutate (sorting in place, removing elements, etc.), the new shorthand will break. The fix is straightforward — use Collectors.toList() when you need mutability, Stream.toList() when you don't — but the failure mode is a runtime exception, not a compile error.

Prefer Stream.toList() by default (immutability is usually the right default), and reach for Collectors.toList() only when you need to mutate the result.

Source​

• JDK-8180352 — the JEP that introduced Stream.toList()
• Java 16 release notes

The problem with single-stage builds​

A naive Dockerfile that installs Maven, compiles a Spring Boot app, and runs it ends up with Maven, the JDK, and all your source code in the final image — easily 600–800 MB.

# single-stage — too much in the final image
FROM eclipse-temurin:21
WORKDIR /app
COPY . .
RUN ./mvnw package -DskipTests
CMD ["java", "-jar", "target/app.jar"]

Multi-stage: build in one image, run from another​

# Stage 1: compile
FROM eclipse-temurin:21 AS build
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN ./mvnw package -DskipTests

# Stage 2: run — just the JRE and the jar
FROM eclipse-temurin:21-jre AS runtime
WORKDIR /app
COPY --from=build /app/target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

The --from=build instruction copies only what you explicitly ask for from the build stage. Docker discards everything else.

Result​

Smaller image = faster pulls, smaller attack surface, less to scan for vulnerabilities.

Tips​

• Name your stages (AS build, AS runtime) so --from= is readable
• Cache the dependency download layer separately by copying pom.xml before src/ — Maven will skip re-downloading if pom.xml hasn't changed
• Use a distroless or Alpine JRE for even smaller images

Have a Docker tip? Write a TIL or article and share it with the team.