Configure This!

Written on 3:45:00 PM by S. Potter

Lately I have had the severe misfortune to return to the J2EE/JEE5 arena after a blissful haitus of 9 months in pure Ruby (and a little bit of Python, for good measure). I have come to the conclusion in a previous life I must have been a serial killer and now karma has come back to bite me in the ..... In theory, being able to configure every detail of the whole world around you sounds great. Afterall, flexible software is a key selling point for management to buy-in to your project. But at what point did we decide to sacrifice developer productivity and sanity for redundant flexibility? Sure JEE5 folks will say: "What configuration? We got rid of all those ugly XML files with Annotations, so you got no'hing on us". I say: "If a bird floats on water, quacks and waddles, it is, most likely, a duck!". If we only take away one thing that Rails demonstrates well, it should be how conventions should be applied over mandatory configuration for the majority use cases. Java heads take note or Java might as well be dead in the water. With .NET and more agile languages like Ruby and Python as competitors for real world server, utility and UI applications, what hope does Java have of surviving the future? Sure, just like COBOL programmers, Java heads will be needed for legacy system support for years to come, but when good, seasoned and well-rounded software engineers are asked what they really need from a development environment, they overwhelmingly shout from the top of their lungs, "productivity and sanity!" At every turn in J2EE we need to read, write or respond to properties set by either the container, the -D parameters passed in and sometimes environment variables set by the deployer. For example, we can't access another EJB (even locally) without grabbing a set of properties that defines our "context". Only then can we have access to the EJB and invoke methods on it. I am sure the Java heads out there are thinking:

What else would someone do? We need all that flexibility in case we change the JNDI implementation, the EJB container, the database, etc.
Apart from giving them the easy response of "How often to production systems swap out core infrastructural peices like that?", I will suggest Java heads consider the following, "How many times has a J2EE/JEE5 developer swapped out an infrastructural peice in 5 minutes with all this configurable flexibility?". Sure we can do a lot through annotations now and that does improve code readability and declutter somewhat, but doesn't solve the real issue. I suggest that perhaps the Java world has been chasing a dream that does not mesh with reality and one that has severly sacrificed our productivity and sanity.