Tomcat is an archaic goddamn mess with so many pitfalls and difficulties to get it actually performant on a production system it isn't even funny to make memes out of it.
Not to mention the crap tooling choices (ant vs gradle vs maven), the tendency of Java applications to eventually bloat in RAM consumption over time due to memory leaks or the fact that Java unlike PHP doesn't punish a developer for wasteful development. With Java apps, startup times of minutes are the norm, the worst thing I ever saw written in it was an "enterprise" CMS (!) that, while definitely more capable than Drupal or Wordpress, takes a 32GB RAM machine to develop on, wants a 64GB or more machine as hosting and takes half a goddamn hour to boot.
It's so hard to get it configured right that instead of deploying your app to Tomcat, you embed Tomcat in your app and letting the framework deal with the configuration, like in Spring Boot.
Of course it means you end up with several dozen/hundred/thousand copies of Tomcat...
That's even worse for optimization since now you have to deal with whatever your framework does to get Tomcat up to speed and how to set a configuration option for Tomcat in a way that eventually ends up at the correct place.
And now I have to deal with this supremely crappy Spring Boot which would convert compile time Java errors to runtime exceptions. Turn already verbose 100 lines stack trace from Java into 5000 lines of Spring infested stack trace. I guess I just couldn't praise enough this Spring Boot.
The only four things that I remember that ended up with crappy run time errors that totally should be compile time Java errors are none specifically related to Spring Boot, they're all generic "Java things":
* people using Win boxes for development and therefore antivirus locking files in innoportune times during compilation/packing;
* people using the Eclipse Java Compiler, a IDE compiler designed to be useful with bad Java;
* people trusting themselves writting XML annotations instead of Java annotations, and not unit testing the code (this lack of unit tests alone probably means the code literally did not even work on their machine);
* people using the existential, compile-on-runtime terror that is Java Server Pages.
I smile not only because you are right but also because tomcat looks like sweet little server compared to next level of crappiness peddled by IBM/RedHat/Oracle etc which I have misfortune to deal with.
I have just watched an ops team say "hey there's a security problem with our version of Tomcat, we need to update it", and then nothing works anymore for a few hours until they get every problem.
My observed odds of a point version upgrade on a normal web server breaking something is 0%. That includes Microsoft IIS, that is a patently known piece of shit.
My observed odds of a point version upgrade on Tomcat breaking something is 100%.
Not to mention the crap tooling choices (ant vs gradle vs maven), the tendency of Java applications to eventually bloat in RAM consumption over time due to memory leaks or the fact that Java unlike PHP doesn't punish a developer for wasteful development. With Java apps, startup times of minutes are the norm, the worst thing I ever saw written in it was an "enterprise" CMS (!) that, while definitely more capable than Drupal or Wordpress, takes a 32GB RAM machine to develop on, wants a 64GB or more machine as hosting and takes half a goddamn hour to boot.