How Java Changed Programming Forever
snydeq writes: With Java hitting its 20th anniversary this week, Elliotte Rusty Harold discusses how the language changed the art and business of programming, turning on a generation of coders. Infoworld reports: "Java's core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants."
Why does it feel like Oracle is advertising Java with these stories...
Maybe it's the applications. As you note, we have proved, time and time again, that in contrived scenarios Java code can meet or even beat the performance of so-called "performant" languages like C, C++, Lisp, VB6, or JavaScript. And when presented with such evidence, most sane, open-minded opponents will hang their heads in shame and promise never again to spread such slander.
...but then, they fire up Eclipse, or NetBeans, or Guiffy, or enable the Java support in their browser, or try to run an app on their favorite feature phone. And they wait for it to become responsive...
...and wait...
...and wait...
...and wait...
...and wait...
...and...
...what did I promise never to do again? Sorry, must have dozed off...
"I decided I could write something better than everything out there in two weeks. And I was right." - Linus Torvalds
I don't have any philosophical issues with Java, but the "simplicity" of it has led to software vendors thinking they can hire simple people to write mission-critical software, with terrible results.
At work, we have several pieces of server software written in Java, and they are just awful. The RSA server, an auth server from Cisco, and others. They crash when the wind blows the wrong way. They bloat and need to be restarted every few months. One executable starts multiple network services on multiple ports. They rely on using dozens of threads with dozens of queues, and there is no way to inspect them. Logs show high volumes of Java call traces and error messages, even when the software is running fine. Sometimes components just stop working, we call the vendor, and the vendor instructs us to restart and/or reboot.
With the RSA server, we had a massive outage one time because an admin kicked off a few reports. It turns out the reports hung a few threads, and took down the service for the whole enterprise.
The Cisco server has the same problems: dozens (hundreds?) of threads with dozens of queues, and the synchronization among the threads just doesn't work 10-20% of the time.
It's not just these servers. In a previous role, we had some Java middleware that translated DIAMETER RADIUS in a service provider setting, and that was it. That software blew up every month or two, and we had to fail the service open for all our customers.
Terrible, flaky, unreliable software. Again, I think it's probably not the language, it's the shitty, shitty programmers.
But, hey, it's job security for me!
Type erasure, on the other hand, is pure evil - to me, it's the representation of what happens when a pragmatic language ends up into the hands of computer scientists.
By the way, in Java all lists have the get() method with no exceptions (this includes Lists, HashMaps, Vectors) and all collections have the iterator() method with no exceptions. The At() method doesn't exist.