The response I dont see represented is that we were more ambitious in the past. There were all kinds of negative effects, bad tools & out-of-touch architecting that was begot; we can acknowledge that, certainly. But that almost all representation of Java here so emphatically emphasize only the negatively bias, without recongizing also some of the idealism, hope, & progress is to our loss.
We were also trying really cool things with many of these java efforts. Rather than a main() routine that imperatively did everything, there were future-sightes notions that we could have a bunch of ambient systems available & interconnected. OSGI solved some thorny library versioning problems, and as a bonus allowed for a very strongly manageable runtime for modules. EJB brought objects up to a higher level, a greater management tier with more interoperability of objects across instances. We were interested in trying more, in tackling harder problems, that microservice era has masked over, deliberately chosen to ignore.
Over time we got more refined forms of many of these systems. Maven calmed much of the ad-hoc madness of Ant. CDI was a more reasonable EJB with event more competent management. JSP kept getting better component libs. OSGi actually was... decent all along, sometimes legit useful.
But the idea that Java was absurdly troubled seems to endure & be enormously popular hatred/FUD to spread. The fads of today are exactly the opposite of the better managed more flexible runtime trend, where the JVM keeps rising as a more capable, flexible, malleable, adaptable, controllable way to tackle processes than the processes at an OS level. And certainly, there's a lot of ease we've bought ourselves by doing much much less. Statically compiled binaries are an example of yet another means of doing less, of finding easy routes; powerful simplifications that have greatly eased many folk's lives.
Less is great, sure. Isolated container instances with dedicated apps is pretty easy to deal with. But there are still constant undercurrents, pushing us towards more interesting complected runtime arraingements, where virtual machines (not fully virtualized os'es but systems like glassfish or erlang, where many sub-processes are co-resident) come back. The idea of very quick very easy to spawn sub-processes allows for interesting security & modularity, where-as today services are almost all monolithic app servers that have complicated multi-user authentication & authorization concerns. We could make simpler safer software if we had more complex runtimes; it's a trade-off, and im deciding we have gone too-deep, unleashed monsters, we have perhaps too polarized ourselves against many of the great capabilities we one tried for.