Anti-Pattern - The Swiss Army Effect
When I was old enough to join the Cub Scouts, my father got me a really impressive Swiss Army Knife. For an 8 year old boy this gift was pretty cool, and I proudly lugged the thing around with me on all of our camping trips. I cannot recall all the tools, but there were several blades, screw drivers, can openers, and I distinctly remember a corkscrew.
After the "new" had worn off, the knife disappeared somewhere into the bowells of a dresser drawer. I didn't lose the knife, I just discovered that it wasn't all that practical. I never did use all the blades, and the tools that I did use were encumbered by all the superfluous ones.
I'm sure that you figured out where I was heading with all this when you read the title of this blog. Don't get trapped by the Swiss Army Knife pattern. Don't add too many "blades" to your applications. Build focused tools that solve specific problems.
All of that is true, but it's also far from controversial. Why waste time blogging about it?
Why indeed? Because I want to make a different point. In many ways, Java is becoming a great big Swiss Army Knife.
I am not real happy with the oposition by IBM, BEA, and Oracle to the JDO 2.0 jsr, but embedded in their arguments is a valid point ( see Three votes no on JDO by Daniel H Steinberg ). The J2EE specification is huge and Java development is complicated by too much flexibility. In this specific case, EJB and JDO both specify a persistence mechanism. EJBQL and JDOQL greatly overlap and both are subsets of JDBC's capabilities. Why not agree on a common core and deprecate the duplications?
I tried to make this point in my earlier blog: Make JDO the "P" in CMP. JDO and CMP should be complementary rather then competing solutions
The EJB/JDO overlap is just one symptom of Java's march to complexity. Perhaps we need to expand the mandate of the JCP to include consolidation and deprecation rather than just expansion. Our knife already has plenty of blades ;-)
(Cross posted at The Thoughtful Programmer)