> Looking back, the main problem was probably Spring, Glassfish, IOC, XML, Maven and numerous other "EE" things that java-people assumed were a must 10 years ago.

Most of those things aren't even Java-specific.

IOC is just a design pattern that asks you to consider whether you should be writing a web server or, say, a request controller that runs on a web server. Since the web server invokes your controller method when it gets a request, we say "control is inverted", because the server is actually driving your application. You are surely doing something similar in any other language you choose, whether or not they tell you it's IOC.

As a whole - from the user (programmer) perspective, Java EE is in fact mostly just a collection of such IOC patterns that have been provided for you to "fill out". This is a servlet template, this is a filter template, etc...

XML is XML, nobody argues that it's not verbose, but it's not difficult to write. With a DTD file specified, an intelligent editor like IntelliJ will suggest element/attribute options for you, which is about as easy as it can get. It's certainly better than a properties file where you don't get any auto-suggestions, but if you want something a little more imperative you can also configure most components programmatically now (i.e. you get a configuration object that you can set settings on, then you call "build()"). Spring and Hibernate both support it, at a minimum.

Glassfish is just an application server. I don't use it, Tomcat is more than enough for most web apps and in fact you can usually get away with a "thin" server like Jetty in most cases.

Spring is such a broad topic that it's almost pointless to talk about. Are we talking about just Spring? Spring MVC? Spring Test? Spring Boot? Spring Security? Each of those solves something different, and frankly each of those also happens to do it much more cleanly and efficiently than anything that came before. Having worked with Struts and directly with low-level Servlets, Spring MVC is a breath of fresh air.

The basic Spring is just a dependency injection system. For most people, that boils down to a nice way to auto-build your ORM instance and inject it into your controllers. You can take it or leave it, it's about a page of code to replicate it in most applications, but it gets increasingly useful in more complex applications and with more complex use-cases because it lets you side-step the question of what environment you're running under in the code itself, and push that into configuration. You can run integration tests against a specific testing database, a SQLite you set up just for the test, etc, and the application doesn't need to know.

Maven is actually the most fantastic thing about the entire Java language. It's a universal project file format that is understood by every single IDE on the market, no more messing around with putting libs in classpath. It's also one of the few 100% reliable packaging systems that I've ever worked with, it will Just Work, 100% of the time, no matter your environment. I've spent so much time fighting pip and bundler over system libraries that need to be installed, 64-vs-32-bit problems, not liking cmd or Cygwin environments, etc. The only complaint I can make about Maven is that you can't just pass it a directory of libs and say "include these"... but it's very obvious why it doesn't do that, it kind of destroys the purpose of explicitly specifying your dependencies. The solution of declaring a local repository inside your repo is less than obvious, but it works. And again, on the whole it's much better than Ant. I would actually rather use a makefile than use Ant.

In general you're right that there's certainly tools that will let you overengineer things if you try. Who could argue with that in a world where AbstractSingletonProxyFactoryBean exists? A lot of this comes out of patterns promoted in the book Effective Java, which is pretty much the definitive tome on the subject and is actually mostly very sensible stuff. But people read "maybe think about using a builder instead of getters/setters", totally miss the point (making objects immutable) and run with it, and soon you've got BuilderBuilderFactory and all kinds of other nonsense floating around just because they're blindly following the pattern instead of thinking it through. The actual problem in Java is that there's 20 years of such cruft and mistakes built up in some frameworks, but other languages are not free from the same effects.

The key is figuring out what subset of features and patterns you actually need and ignoring the rest. Java is not a one-size-fits-all solution where "There's Only One Way To Do It", it's a massive toolbox and you probably aren't going to need those Torx screwdrivers to change your oil. If you try to use everything in every project just because it's there,
you're going to have a bad time. But you can rest assured that you have options if you ever need them.

If you're looking for a curated system of tools that are known to work well together, I urge you to consider Spring. Spring MVC is your equivalent to Rails, running it in Jetty is usually more than enough for basic web apps. The Apache Commons libraries are also very good for taking the edge off of some of the verbosity (they provide high-level equivalents to common operations on low-level objects), and are very high quality in general.

Also, to agree with a sibling comment, IntelliJ is definitely the way to go. Jetbrains stuff is just always so perfectly on the money.