Older, widely used code rarely treats the Single Responsibility Principle (SRP) as a strict contract. Each method does roughly one thing, but the edge cases (nulls, mutability, memory, fallbacks) are decided case by case:
Date / SimpleDateFormat are mutable and not thread-safe.List.of(...).contains(null) throws NPE.Collections.unmodifiableList is only a view - changes to the original list still show through.Integer.parseInt(null) throws NumberFormatException instead of NullPointerException.Arrays.sort(a, null) silently falls back to natural order.
Each exception is small, but together they mean that names can't be trusted, so every piece of documentation has to be read. Documentation stops being clarification and becomes a list of exceptions you have to remember. Newer APIs are somewhat better, but lost trust is hard to rebuild. The old warning "always read the documentation" was never about good practice - it was about code whose names could not be trusted.
Current code is easy to write and read as long as it fits conventions, but whenever something goes beyond them, we see more errors and less clear code.
Conventions become harmful when they collapse multiple domains into one while only partially handling each of them. Later, developers mistake that partial pattern for the correct model; with time and popularity, it's taken as proper design.
