The lack of operator overloading makes it impossible to implement new numeric types in a consistent way. For example imaginary numbers or numbers with units.
You can make the case that both intX (x=16, 32, 64) and floating point are bad for general purpose computing. Like Common LISP and Python, Java has bigints and rationals in the stdlib, but Java makes you use non-operator syntax to get at them. Contrast that to Clojure which puts them on your fingertips.
Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)
Java has always been in a strange place of not deciding if it wants to be a systems or application language. (The standard architecture is that demanding systems, say video games, are written in both a systems language and a scripting language. A Python coder feels smart when the incorporate, say, number is written in C or FORTRAN but Java’s xenophobia makes that feel like a personal failure. Java is ‘good enough’ for applications programming that you might find something like Spring or Guava gives you all the dynamism you need with less hassle than adding an embedded scripting language like Groovy or Clojure.)