intermediateLiskov Substitution Principle

What is a real example from the Java standard library where a class technically satisfies an interface but violates LSP?

List.of(...) and Arrays.asList(...) both return List implementations that are fixed-size or immutable, yet they implement the exact same java.util.List interface that mutable implementations like ArrayList implement. Calling .add(), .remove(), or .set() on these lists compiles perfectly, since List declares those methods, but throws UnsupportedOperationException at runtime instead of actually performing the mutation. Any method written generically against List, trusting that add() is always safe because the interface declares it, can be handed one of these immutable lists and crash at runtime with no compile-time warning at all. This is a documented, intentional trade-off in the JDK for memory efficiency and safety around accidental mutation, but it remains the textbook real-world illustration of an LSP violation, since it is exactly the same shape as a ReadOnlyFile throwing from write().

Ready to master this question?

Generate a complete walkthrough — background, the full answer in plain language, a working code example explained line by line, a real-world scenario, common mistakes, and how this same question gets asked in different ways.

Sign in to generate a response

Next Step

Continue to How do ORM frameworks like Hibernate use the Proxy pattern for lazy loading of related entities?← Back to all Low-Level Design & Design Patterns questions