What’s wrong with Java is all the choices…

Admittedly the title is somewhat tongue in cheek, but after a recent blog entry (I’m sure you can find it) and having a look around the blogsphere for responses (http referrer logging is very useful) it is clear to me that Java developers are different in some ways, and much of this is due to the design of the Java APIs. I’ll use the stereotype “Java developers” for convenience, and because that’s how many respondents viewed the group, but I believe it’s a different group entirely and that Java developers aren’t a single stereotype any more than “Perl Hackers” or “VB weenies” are.
In the Java world there is a lot of infrastructure (those pesky “morass of factories”) that allows for alternative implementations to be substituted. This allows people to write code that conforms to a single API and only change the behaviour based on the implementation. This gives great runtime flexibility, and especially for much of the code that I write (crypto) it allows for flexibility in the legal arenas where different strength crypto is allowed in different countries. Also, there are countries that have patents for particular algorithms that don’t exist in other countries. One of my comments which was taken out of context on use.perl.org obviously didn’t understand this, or didn’t even try to understand that different world view. Again, why should they, they’ve probably never had to build something like that in their life, so it’s completely foreign, strange, and in their view, wrong.
Now, as many Java developers have been users of the Java API’s (well, duh) it is natural that their implementations have also been influenced by their experiences. Now in some cases this is good, and in some cases this is bad. It’s good when it’s clear and obvious (using a different JDBC driver, different JCE provider, different JDO implementation) and it’s bad when it weird and confusing (no example off the top of my head, but I’m sure there are lots).
What the Java development world is doing is trading off is runtime flexibility with compile time decision making.
I’m now going to talk about Perl, something that I’ve had a lot of experience with (which is why I have been confused that the Perl people have been slagging off at me, I never said anything bad about you guys, back off), but I’m sure it equally applies to other languages/implementation/developers. When writing a Perl program I have to choose what implementation of a library I want to use, will it be Cache::Cache, Cache::FastMemoryCache or Cache::Mmap (please, I’m not picking on the implementation, I just did a quick browse of CPAN looking for alternative implementations that didn’t share a common interface). For a developer, I need to know how my software is going to be used, and the environment and the potential pitfalls of each. What’s more, it makes it harder to mock out the specific implementations for testing, when the code is relying on a concrete implementation.
Is this bad ? In general, no. Is this different to how I think ? In general, yes.
I’m not smart enough to be able to guess how my code will be used by somebody else, so I like to reduce coupling and allow for different implementations to be substituted during runtime. Much of this is due to my experience with Java, but it’s also based on bitter real world experience where I need to have this reduced coupling because in more cases than not, I’ve needed this flexibility. Using a scripting language (Perl for example) much of this can be resolved by having different and specific implementations in each environment. I’m sure this is fine for many people, but when I’m shipping class files to a customer, they don’t have the ability to change the code for their environment, so I have to allow it beforehand.
So, the next time you wish to have a rant about how hard something is to use, how it seems over-engineered, take a long deep breath and imagine that you’re not always right, and that sometimes it’s out of necessity rather than some perverse need for complexity and that maybe, just maybe, the people that wrote that code actually did know what they were doing.

Advertisements

One thought on “What’s wrong with Java is all the choices…

  1. Ideally, we want the easy (common) things to be easy, and the hard things to be possible.
    So a high-level class/method that uses the most common default options for everything and gets the job done will help those who need something simple, and ALSO serve as an example of what has to be done to use the rest of the framework – factories and all.

Comments are closed.