I think one thing that this post touches on is the effectiveness of Java as a programming language for large projects. Although personally I've moved on to Python since it greatly simplifies web-related tasks, a lot of our legacy projects are in Java and I still hear plenty of people sipping the Java haterade. So I thought I'd share some of the most common things I hear.
Only my grandpa writes in Java anymore.
I hired a junior developer a couple months ago who absolutely refused to write code in Java, swayed by the vitriol that is often spewed by highly opinionated developers against Java. Instead of taking the time to learn the language, he read up on all the Java Versus Everything Else rants out there and emailed me links to them, trying to convince me that his arrival meant our code base should be rewritten in a "more modern language". Needless to say that he didn't last very long.
The fact remains that Java is an incredibly mature language that runs much faster than most other solutions, and makes it significantly easier to handle the complexity of a large project. There is an enormous ecosystem of libraries for Java, and it would be foolish to move to a less mature language which needs more wheel reinvention.
Garbage collection is bad.
There are the obvious downsides to garbage collection, e.g. Android apps running on low-memory devices, but for an enterprise application running on a server you shouldn't be breaking balls about garbage collection. Obviously it would run 10 - 30% faster in C, but we live in a day and age where it is cheaper to provision extra servers than it is to pay people for the extra man-hours they spend gdb-ing for segfaults and valgrind-ing for memory leaks. It is much easier to pick up a good Java developer than a good C developer, because the good C developers have already been picked up by the big companies that actually need the performance advantage. And from my experience working in a company on an enormous C code base, I know firsthand how easy it is to pick up a really shitty C developer.
It seems like most of my Java code is just checking for errors.
Would you rather not check for errors? What I mean is, would you rather allow a single developer's "return null" statement that was absentmindedly used to handle a rare edge case to completely fuck your application when that edge case is actually reached? Pardon my French, but I'd rather take the time to throw/catch exceptions than get fucked by a gung-ho developer's null, since Java will force exceptions to be caught and handled at some level. With a well-architected solution, error handling can be centralized and developers can more easily contribute to the codebase if the throw-catch paradigm is part of the coding standard.
Java's GUI capabilities really suck.
This one can't really be refuted - Java's Swing UI components are indeed quite shitty. But you can work around them by creating your own Swing components, and enjoy the benefits of a cross-platform solution.
I know this rant was long, but a lot of it was taken from emails that I've sent to my devs in our Java vs. no-Java threads. I'm no Java fanboy, but I am better than most at seeing past the haterade to where it works and where it doesn't work. Maybe I'm wrong, but my experience is a bit more practical than just reading an article that nitpicks at Java's perceived downfalls.