There is so much negativity around Java that I wonder why anyone starting on their journey to becoming a programmer would want to learn it or work with it.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" -- Bjarne Stroustrup [1], Creator of C++ [1] http://www.stroustrup.com/bs_faq.html#really-say-that
- It was kind of the Golang of the 90s, where each class had a clear and limited purpose -- but it also meant you had to chain three or five classes together to get anything useful done [1]. For this and other reasons, like the longtime lack of type inference, earned it a reputation for verbosity.
- Most people don't have a clue how to design software, so they turned to outside resources for ideas. The 1994 book 'Design Patterns: Elements of Reusable Object-Oriented Software' [2] introduced a lot of useful models on how to translate mental models into object-oriented code. Some systems sprawled too much to where their implementations started to look like this model gone horribly wrong, while some developers merely ingested these ideas as a dogma and went on to produce code that was needlessly complex and poorly thought-out.
- At some point a bunch of licensed code originating from a venture of IBM was dumped into the JDK, hence the awful, miserable mess that was datetime and calendaring [3] before Joda-Time's Stephen Colebourne brought sanity to it with Java 8.
- Applets were punching above their weight, but the tech was poorly implemented, and, as history proved with it and other plugins like Flash, woefully insecure. Vulnerabilities in Java Applets, and early public confusion about Javascript vs. Java perpetuated the stereotype that Java itself was broken, insecure, or both.
- Consultancies are big business, and companies like IBM, Oracle, and SAP would happily sell shops on big application servers with monitoring and control panels and genuinely useful stuff, but also tons of cruft and bugs. These players emerged from the J2EE spec, which defined useful APIs but intentionally left the implementation unspecified, to cultivate a thriving community of alternative implementations. Predictably, this didn't go as hoped.
- People are obsessed with customizing their software, so vendor-delivered products were built with externalized configurations. Some people took this way too far, resulting in the familiar nightmare [4] where you had to configure mounds upon mounds of XML or .properties files to get an application running. It didn't help that this was actually the better way of getting it done in Java, with the Spring Framework, which was way more palatable to work with than the alternatives coming out of the J2EE spec.
- Rails shook the world at the end of 2005 and showed that the obsession with configuration was dumb [5]. Scrambling, both Spring and EJB received rewrites, so now Java devs @hardcoded things directly into the source code with @annotations (that are by the way "not code!", as if that distinction was at all relevant) and pretended they were enlightened.
- Sun had a vision for Java that they were never truly able to execute. In the process, they delivered a pretty solid language, eventually backed by a fantastic VM [6], that became popular because it was simple and scaled down well to okay and decent programmers -- not requiring a fleet of expensive rockstars. Oracle smelled money and bought it up, and despite additional innovation still being delivered by its staff, created wariness and distrust in the Java community by its corporate attitude.
[1] http://stackoverflow.com/questions/4716503/ [2] https://en.wikipedia.org/wiki/Design_Patterns [3] https://java.net/nonav/projects/jsr-310/lists/dev/archive/20... [4] http://thedailywtf.com/articles/Soft_Coding [5] https://news.ycombinator.com/item?id=12761705 [6] https://news.ycombinator.com/item?id=12160439