Yeah, I think the garbage collection was a big factor. Especially in comparison to C++. JS is not compiled, so the real competition was only C++. Still I would always choose it over Java :D something about the syntax probably...
Sun Microsystems was the leader in the enterprise server market in the late '90s (cue the hokey "the dot in dot-com" ads) but the other server/workstation vendors and Microsoft were hot on their heels. Java caught on quickly because they put an enormous amount of money, effort and evangelism into driving Java everywhere in hopes of creating a new ecosystem under their control to serve as a moat, succeeding primarily in enterprise markets where they wielded an enormous amount of clout. That plus its own merits were enough to overcome its significant demerits, mainly speed and, for lack of a better word, grottiness.
Over time, it evolved into a passable language, the one you see today.
As James Gosling put it, "Java is C++ without the guns, clubs and knives." The language was familiar to most existing programmers, but solved a host of problems that could be real time sinks.
Garbage collection was the most prominent. Prematurely freeing memory leads to failures that can crop up only long, long after the actual error, often at random. You just get crap stuck in your memory with no idea who put it there, or even when, and you couldn't protect yourself from it.
Moore's Law meant that we could begin to afford the overhead in time and memory, while saving developers untold hours. I watched development come to a complete halt because a bug simply could not be solved.
In most environments, C programs wouldn't even be able to give you a stack trace. All you got was "Segmentation violation -- core dumped". The first time I saw a null pointer exception with a stack trace, I wept.
There were a million other good things about it, a lot of which have been adopted or made obsolete. But the memory management alone made it absolutely obvious, especially in fast-moving development environments where getting code out the door was more important than eking out the last drop of performance.
7 comments
[ 3.0 ms ] story [ 44.8 ms ] thread1. It was free.
2. Jave code ran unchanged on Sun/Solaris, Windows (95?), and Mac OS.
3. There were GUI components that would sort of look like Motif, Windows, Mac. There was no other multi-platform GUI library that was usable.
4. It had garbage collection. This was a big win.
5. It had the JNI so I could write a Java to C interface layer to the distribution library (COBRA). Later the vendor wrote a 'real' Java interface.
6. It was free, and available for download without budgets, purchase orders, management approvals, and multiple layers of no-sayers.
I had a GUI demo running on a Mac laptop, a Windows box, and a Sun box talking to our servers after one weekend day of programming.
We were not using web browsers or web servers in our system.
7. Java was easy to learn, compared to languages similar in features, such as C++.
8. Java is easy to debug. No memory corruption, core dumps etc.
9. Tooling: Java IDEs were fantastic! I cannot say the same about C++ IDEs, 20 years later.
Over time, it evolved into a passable language, the one you see today.
Garbage collection was the most prominent. Prematurely freeing memory leads to failures that can crop up only long, long after the actual error, often at random. You just get crap stuck in your memory with no idea who put it there, or even when, and you couldn't protect yourself from it.
Moore's Law meant that we could begin to afford the overhead in time and memory, while saving developers untold hours. I watched development come to a complete halt because a bug simply could not be solved.
In most environments, C programs wouldn't even be able to give you a stack trace. All you got was "Segmentation violation -- core dumped". The first time I saw a null pointer exception with a stack trace, I wept.
There were a million other good things about it, a lot of which have been adopted or made obsolete. But the memory management alone made it absolutely obvious, especially in fast-moving development environments where getting code out the door was more important than eking out the last drop of performance.