Using java.nio.file.Files and HttpClient as examples, explain the trade-offs of using a JDK facade versus dropping down to the underlying subsystem.
answer
- Facade = 80% case + safe cleanup
- readAllLines/readString = EAGER full load → OOM risk
- Files.lines = lazy stream; FileChannel/MappedByteBuffer = control
- HttpClient.send blocks; sendAsync + BodyHandlers for streaming
- Facade first; drop down only when a concrete requirement forces it
basics
~20 sFacades like Files.readAllLines or HttpClient.send make the common case a one-liner and handle resource cleanup for you. But they load everything eagerly or assume defaults. For huge files, custom buffering, memory-mapping, or fine HTTP control, you drop to FileChannel/SocketChannel and configure it yourself.
solid answer
~50 sA JDK facade optimizes for the common case: it is concise, discoverable, and safe (it closes resources for you). The cost is that it hides choices you sometimes need. Files.readAllLines and Files.readString read the *entire* file into memory eagerly — fine for config files, an OutOfMemoryError risk for multi-gigabyte input, where you want Files.lines (a lazy Stream) or a FileChannel with your own ByteBuffer, or a memory-mapped MappedByteBuffer. The facade also picks defaults: charset, buffer size, no random access. Similarly HttpClient.send is a blocking convenience over connection pooling and HTTP/2; if you need streaming bodies, custom TLS contexts, or async backpressure you use sendAsync with BodyHandlers or configure the builder, and for raw control you'd use channels/sockets. The senior judgment is: start with the facade for clarity, and only reach into the subsystem when a concrete requirement (scale, latency, memory, protocol control) forces it — never preemptively, because the facade is also the safer, less bug-prone path.
go deeper
Knows the facade is the easy/default way and that Files closes resources for you.
Can name a limitation (eager full read) and the alternative (Files.lines / FileChannel) for large files.
Articulates the full trade-off (conciseness/safety vs hidden defaults/eager loading), maps requirements to facade-vs-subsystem choices, and knows streaming facades still hold resources.
Frames a team policy: facade-first with documented exceptions; weighs maintainability and leak-risk of bypassing, and considers exposing internal subsystem access deliberately in their own libraries.
## Recap: what a facade is here A **facade** in the JDK is a high-level convenience API that hides lower-level *machinery* — a *subsystem* of cooperating classes. `java.nio.file.Files` is a facade over the NIO file subsystem (`FileChannel`, `ByteBuffer`, `Charset`, `Path`, `FileSystem`); `java.net.http.HttpClient` is a facade over connection pooling, HTTP/2 framing, TLS, and redirect handling. The pattern's promise is *simplification*; the question is what that simplification costs. ## Benefits of using the facade 1. **Conciseness.** `Files.readAllLines(path)` replaces a multi-line open-decode-buffer-loop-close sequence. 2. **Correctness / safety.** The facade performs resource management for you — it opens and *reliably closes* channels even on exceptions, eliminating a whole class of resource-leak bugs that hand-rolled code gets wrong. 3. **Discoverability.** A developer finds `Files.copy` or `HttpClient.send` immediately; assembling the equivalent from the subsystem requires knowing the machinery exists. 4. **Decoupling.** Calling code depends on the small facade surface, so internal implementation can evolve without breaking callers. ## What the facade hides — and when that hurts A facade serves the **80% case** by baking in defaults and an eager, all-at-once strategy. The hidden choices include: - **Eager full-load.** `Files.readAllLines(path)` and `Files.readString(path)` read the *entire* file into memory and return it. For a small config file this is ideal; for a multi-gigabyte log it risks `OutOfMemoryError`. The subsystem-aware alternatives: `Files.lines(path)` returns a **lazy** `Stream<String>` that reads on demand (still a facade, but a streaming one — and note it must be closed); a `FileChannel` with your own `ByteBuffer` gives chunked control; `FileChannel.map(...)` returns a `MappedByteBuffer` (memory-mapped I/O) for very large files or random access without copying into the heap. - **Fixed defaults.** Charset (often platform default unless you pass one — itself a footgun), buffer size, and *no random access* (the facade reads start-to-end). Need to seek to byte offset N, lock a region, or pick a precise buffer size? That is `FileChannel`/`SeekableByteChannel` territory. - **No streaming/backpressure control in the simple HTTP path.** `HttpClient.send(request, BodyHandlers.ofString())` blocks and buffers the whole body. For large or streaming responses you use `BodyHandlers.ofInputStream`/`ofLines`, and for non-blocking flow you use `sendAsync` (returning a `CompletableFuture`) with reactive `BodySubscriber`s. Custom TLS, proxies, connection timeouts, and HTTP version are configured on the `HttpClient.Builder`; deeper still you would manage `SocketChannel`/`SSLEngine` yourself. ## The decision framework (senior judgment) The right default is **"facade first."** It is the concise, discoverable, and *safer* path (it handles cleanup). You drop into the subsystem only when a **concrete, demonstrated requirement** forces it: - **Memory/scale:** input too large to hold in RAM → streaming (`Files.lines`, channels) or memory-mapping. - **Latency/throughput:** need async, pipelining, custom buffer sizing, or zero-copy transfer (`FileChannel.transferTo`). - **Protocol/format control:** custom charset, random access, file locking, custom TLS/HTTP settings. Reaching into the subsystem *preemptively* is an anti-pattern: it trades the facade's safety and readability for complexity you may never need, and hand-rolled resource management is a common source of leaks. Conversely, *forcing* the facade onto a case it cannot serve (e.g. `readAllLines` on huge input) is the classic production OOM. The senior skill is recognizing which regime you are in and choosing accordingly — and documenting *why* when you bypass the facade. ## A subtle point: streaming facades close resources too Note that `Files.lines(...)` and `BufferedReader.lines()` return `Stream`s backed by an open file; they are themselves a thinner facade but they hold a resource, so they must be used in try-with-resources. This is a place where the convenience API still requires the caller to understand the underlying machinery — a reminder that a facade simplifies but does not fully absolve you of knowing what it sits on.
- Why can Files.readAllLines cause an OutOfMemoryError?It eagerly reads the entire file into a List<String> in heap memory. On very large files this exhausts the heap. Use Files.lines (a lazy Stream) or a FileChannel for chunked/streamed reading instead.
- Files.lines returns a Stream from a facade — what must you remember?It keeps an underlying file resource open, so the Stream must be closed (use try-with-resources). The convenience API still wraps a resource the caller is responsible for releasing.
saying these in an interview costs you the question
- Claiming the facade is always the right choice regardless of data size — readAllLines on huge files OOMs.
- Preemptively hand-rolling FileChannel/socket code 'for performance' without a measured need, losing the facade's safety.
- Forgetting that streaming facades (Files.lines) still hold an open resource needing try-with-resources.
- Assuming the facade uses your desired charset — defaults can bite; pass an explicit Charset.