In the current-day context there are a lot of ways you can improve Java code just by not using OO mechanisms. A lot of the pervasive use of inheritance in the

In the current-day context there are a lot of ways you can improve Java code just by not using OO mechanisms. A lot of the pervasive use of inheritance in the past was driven by the assumption of working in big monolithic codebases in huge teams with long development cycles and really poor use of SCM. Working in small teams, on microservice codebases, in short dev cycles, without long-lived feature branches and late merges, you don't need as much protection against other people's code. You can use concrete classes instead of interfaces, and you can separate data from algorithms instead of finding ways to conceptualize every function as a "behavior" of some anthropomorphized collection of data. A couple of edits: The old style makes sense for the API surface of libraries; I won't dispute that. As much as they annoy me, I do see a bright side to people who insist on defining "correct" Java style as the circa-2000 style motivated by a bunch of long-dead assumptions: they will help Java die. Nobody under forty wants to write code that way. All it will take to kill Java will be for Oracle to declare a future release (say Java 25) as an "eternal support" release and then release an entirely different language as "Java 26" the way Microsoft did with Visual Basic.