There are a few reasons to avoid Java today. - The programs are very verbose for the functionality they provide. There are countless lines of getters, setters, and trivial constructors. While IDE helps to write them, it makes reading existing programs slow and frustrating. Lombok helps, but very few programs use it. - If you do want to use Java ecosystem, there is Scala. It also has strong type system, nice IDE suppo…
- It forces us to go through the ceremony and verbosity of static typing, yet blows away lots of the benefit by pervasive use of `null` and `Object`. Compare this to ML or Haskell, where there's less ceremony (Hindley-Milner type inference) yet more safety (no `null` or down-casting)
- Checked exceptions have a similar ceremony and verbosity problem, yet the pervasiveness of unchecked exceptions prevents us actually having much confidence that calls will succeed. Compare this to effect systems, even rudimentary ones like Haskell's (`Maybe`, `Either`, `IO`, etc.): if a function doesn't return one of these 'effect actions', we can be pretty sure that it will succeed (the only unchecked exceptions I've encountered in Haskell are pretty catastrophic things like OutOfMemory).
- It needs to be compiled ahead-of-time, which requires more tooling, makes automated testing more annoying (we have three different failure-reporting mechanisms: app compile error, test compile error, test failure), tools like REPLs are second-class afterthoughts, etc. Yet the resulting bytecode still requires an interpreter (JVM), which takes a while to spin up, and makes deployment and packaging harder (we don't have a self-contained binary).
- It pushes an OOP style, but requires that we keep subverting it; e.g. pervasive use of using structured-programming constructs like `for` (which other OO languages like Smalltalk avoid in favour of method calls), which requires we break encapsulation/implementation-hiding (e.g. if we loop with an 'Iterator', we need to know whether anything we call will use that same Iterator).
- It seemingly pushes a high-level, highly-abstracted design (methods calling other methods, classes maintaining their invariants, etc.); but then throws threading into the mix, which breaks things into such low-level pieces that even 'i++' needs to be thought of in terms of constituent parts (read, increment, write, return).
I agree that Scala's better (e.g. reducing a lot of the typing ceremony; making it easier to remain high-level/abstracted (e.g. encouraging 'map' and friends rather than effectful loops), etc.); it inherits some of Java's problems (and doesn't even flag checked exceptions!), but it's nice enough to tilt the balance in many cases.