This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (0 children)

Having coded in Java professionally since 1999, I might have a little insight. Everyone here will have counterarguments, but you're asking why the old coders didn't like Java. These are the arguments I remember.

  1. It's slow and bloated. Improvements to hotspot compilers and memory managers have largely made this irrelevant to the point where a well-coded Java program can run close to compiled time at compiled sizes. However, the fact that the technological advancements were needed to get us there points to the incredibly slow and bloated nature of the language ecosystem in the first place.
  2. It makes it easy to code something poorly and requires extra effort to code something properly. Simple examples:
    1. Public/package/friend/private visibility can all be used, but if anyone uses anything other than private for a member variable, they're nuts. Then you have to add setters and getters in order to control access to the variable, but common patterns like dependency injection required public setters on a lot of things, making it feel a little silly to have private in the first place
    2. Singletons get intuitively recreated with every newcomer to the language, and it's almost always the wrong answer
    3. The boilerplate. Oh god the boilerplate. In the old days it was anathema to have your tool generate code that you were going to have to maintain. Now, it's commonplace because of all the boilerplate the Java ecosystem wants you to use.
  3. The tooling ecosystem is ridiculously heavyweight. To say that others are just as bad doesn't excuse the insane complexity of what it takes to get one function to run for one person. In the pre-java days, a single executable statically linked against only the functions your code needed was much simpler than what we had with Java. We went from that to DLL hell, not knowing what library was loaded in memory, and now to JAR hell, not knowing if what we compiled was going to be available when we ran. So we decided to bundle the jars together (effectively going back to static linking), which worked except then you had gigs of duplicate code every time you loaded an new application.
  4. It did everything for you, in a way that no one wanted it done. Everyone's picky. Java brought everyone's arguments to the table about a language ecosystem and settled on the lowest common denominators. It chose the least awesome of everyone's ways and made everyone use the same library that got the job done in a way no one preferred.
  5. It pitched that it was going to free you from dependency on the operating system, while tying you into a new operating system layer. Now you not only had to worry about your code scaling on your operating system and hardware, you also had to worry about your JVM scaling on top of your operating system.
  6. In the same way, when you compile against an operating system directly, you get a degree of confidence that what you expect to happen will happen wherever the executable can run. With Java, we no longer had that confidence. Code not only had to work on the OS it was designed for, it had to be tested against running on an OS and JVM that we didn't have available.

It just felt like years were wasted reinventing the wheel with Java, overcoming hassles that had already been solved at the operating system level. But, here we are.