John Reynolds's Blog

Anti-Pattern - The Swiss Army Effect

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 ;-)

Comments

• J2EE != Java
  J2EE is a set of extension APIs to Java and not part of the core API.
  It is indeed getting to be a big lumbering behemoth and is possibly in need of breaking up into several smaller parts along functional lines (some of which parts may require some of the others but I'm certain there are parts that don't need all the others...).

  The same is possibly true of the core APIs as well. The XML processing capabilities can well be distributed separately, IMO they are NOT core functionality at all.
  Same with Swing and AWT (I never use those, I never write graphical user interfaces rather specialising in web interfaces and batch jobs (which use only files and command lines for input and output).

  I don't mind at all that there are several ways to achieve a goal in Java.
  It makes for flexibility to choose the best tool suited for the job at hand.
  If only one data access strategy were allowed for example, we might as well scrap not only JDO but also JDBC from the public API (after all, there's EJB which is what IBM and BEA want you to use).

  Posted by: jwenting on May 07, 2004 at 02:19 AM

• Swiss Knife
  The many blades we have in java plus extensions are more like the set of swiss knifes which you could have been bought as a boy.
  The question this anti-pattern really asks is:How many of them should you take along into the woods?
  

  Posted by: fforw on May 07, 2004 at 06:02 AM

• J2EE != Java
  I would agree that there are many APIs which are included in the standard distribution but which are not always needed. IMO what we need is a progressive distribution which installs the "Java Kernel" APIs and "necessary" code; only installing other "specialized APIs" and "standard extensions" as needed (when the user executes an app(let) which uses those APIs for the first time).

  If a user never accesses a database, he should never have to download JDBC. Similarly, if he doesn't use programs which require RMI, logging, JNDI, CORBA, etc. those APIs should never become installed.

  Of course this "progressive" install will still need an advanced install button to let the user select other packages that he thinks he will need in the future and wants to install now rather than later (because later he may not have access to the internet for instance).

  However, I would argue that one "standard extension" that needs to be there from the start is Swing. This is because the Java runtime uses it to interact with the user. The Java console and plugin control panel need it. I suppose Sun COULD make that stuff native, but I wouldn't advocate doing that.
  

  Posted by: ekartzma on May 07, 2004 at 09:15 AM

• Swiss Knife
  | How many of them should you take along into the woods?

  Then you are assuming something that the original poster did not. Intimate knowledge of all those technologies.
  I can not choose if I don't already know all of them. Choosing the wrong one (and Murphey says you will) is hugely expensive. (consider re-learning and switching)
  If a company choose the wrong one, and had a huge loss on the project, it will think twice about using Java then next time around.

  The real question is thus not which blades; you can't make that choice until you come out of the woods again.
  The real question becomes whether a hammer and a screwdriver will not save you enough time and headace that they are worth it to be carried with you instead of that lousy knive.

  Posted by: zander on May 08, 2004 at 01:44 AM

• Swiss Knife
  for the ones who did not understand my (not directly obvious) question in the last sentence.

  If the technologies grow too expensive to learn or support; a company will try to create its in house version with more basic tools, and you loose all advantages you wanted from the framework in the first place.

  I know my company did when we first saw EJBs 6 years ago.

  Posted by: zander on May 08, 2004 at 01:47 AM

• J2EE is bloated due Economics meaning that J2EE can only grow because neither Sun nor the real application server vendor can afford to reduce the feature set and are caught in a spiral of adding more and more features to keep their customers interested. I suggested a while ago that J2EE should be splitted into core code and added components like containers, JCA, O/R mapping etc. This would allow an administrator to configure the server to what he/she needs than what a specification defines. Then it would be possible to create an Entity Bean Container supporting JDO instead of Hibernate.
  By the way as a member of the Swiss Army I can tell you that the real Swiss Army Knive only has a few components, is slick and light. The company producing this knives later started to add blades and tools to it because of customers who saw it as a status symbol rather than a tool.
  In our faced paced world of ever evolving technology we forgot to look for the things we need and are rather looking for the most bang for the buck leading us with a lot of features we do not need, which are not only worthless but do even diminishing the overall value of the entire thing. I think we should go back to KISS (keep it simple, stupid) and value a good but simple tool more than a sofisticated and overloaded one. I rather like the simple knive in my military service than these huge and klunky knives or how many times did you see a GI in Iraq with a vine bottle.

  Posted by: schaefa on September 27, 2004 at 02:49 PM

This work is licensed under a Creative Commons License.