Why Java Is A Different Beast

Cote made the following blog post: http://www.redmonk.com/cote/2007/07/25/javas-fear-of-commitment/. And here's my thoughts on it:
Great post Cote. This post is not so much about Java the language, but about Java the community and the Java philosophy/mindset. I wholeheartedly agree with Cote's point, it's something that I have felt as well, and I think he articulated it well.

Java gurus tend to get interface-happy: look at the Springframework and Eclipse sourcecode for instance: where almost every class has a corresponding interface. Do all those classes really need several different implementations? I doubt it.
They also tend to get subproject-happy: applications must have layers and these layers must be clearly separated; The "presentation layer" must not touch "data objects" directly, we need "domain models"; or, Let's have a subproject for each layer of the application to reduce coupling, parts of it can also be reused in other projects. Does the reuse really happen down the road? I won't say never, but I think rarely.
In general terms, the Java Philosophy is this: keep modules isolated, so that they can be resistant to change. Because you never know when you are going to need to swap out your UI layer, business layer, data access layer, or your persistence engine, or your database, or your JMS provider, or your J2EE container, or your OS, etc, etc.
I am not dissing this philosophy, it is very useful to be able to swap out some of these components, but others, not so much. There's a balance somewhere. I think that in a lot of cases simply refactoring code is enough to cope with change. It really isn't hard if you keep your code DRY, and have good test coverage. Java folks in general are just too in love with the idea that their finished code should work with every imaginable situation that can arise to do it this way.

blog comments powered by Disqus