Wednesday, January 14, 2009

Why Most Java Complaints Are Cultural Vs. Technical Problems

For a long time now, I have heard a steady stream of complaints about the death of Java and it's inevitable obsolesence. Yes, some of these have come from Necrobious over the years, but it does seem like there is a building animosity towards Java as a bloated slow way of developing applications.

I don't agree with this.

It's not that I'm not open to the other languages that the bitter Java guys seem to be jumping to. It's that I think most of the problems that they state about Java are related to the culture that has formed around Java development as opposed to the language on its own.

For example, some people jump the Java ship in favor of php, ruby on rails, python, perl, etc. saying that they can't develop quickly in Java. They then go ahead and crank out some apps in those other languages using techniques that could be done functionally verbatim in jsps and servlets, but are not socially acceptable among many Java developers to do in jsps and servlets.

The corporate culture of Java IS stuffy, but that doesn't mean that is a flaw with the language and the truth is that the ubiquity, support, and active open source development communities are a huge strength that some of those other languages can't measure up to.

Like politicians falling over themselves to be more morally pure than other candidates. There is also a "moral ratchet" that occurs in corporate Java development. Don't let this stuff get to you though. Here are the behaviors and buzzwords that you might be headed in to a soulless Java shop. YMMV.

* Excessive abstraction, properties files that reference xml files that reference properties files. Commit to a damn setting already!
* People that choose enforced encapsulation over functionality. It is possible to write good, clean, effective jsp files, but somehow many Java developers flock to emaciated template languages, because they don't trust themselves with the power and flexibility.
* Bloated massive frameworks. Watch out carefully for the bloated, do it all frameworks that seep into corporate shops because managers and timid developers are afraid to learn how to do something themselves and would somehow rather learn how to configure how somebody else has done something. I'm not saying this is true of all frameworks or libraries.
* "Best Practices" - Watch out for the people that say this constantly in defense of their work. It is often used as an "emperor's invisible clothes" tactic.

You get the idea...

No comments: