WordPress plugin licensing: Choose a Java framework

How frameworks came to be

Engineers have a few potentially conflicting tendencies that can become very pronounced in the software they write. One tendency is that we’re empire builders. In other words, we build, enhance, improve and in other ways expand the scope of our software solutions over time. Not to mention that we want our solution to be accepted, embraced and adored as the best possible solution for the problem we set out to solve. The result of this tendency can be seen in the ever growing, ever more complex frameworks available today.

The other tendency is to be overly critical of the software solutions created by other engineers. Sometimes this critical nature comes out as mild concerns related to difficult to test aspects like scalability. At other times it may come out as fundamental objections to the framework architecture. However severe the criticism, many engineers decide to start fresh and build something entirely new that fits their style. The result of this can be seen in the large variety of frameworks available to solve very similar problems.

Two projects that illustrate the points above are the Spring framework based on Rod Johnson’s work, and Google’s Guice framework. Both embrace dependency injection (inversion of control), but they disagree on implementation. While Spring has become an empire, Guice claims to want to remain small and lightweight.

It is very interesting that the tendencies I’ve just discussed have been the subject of academic research. Recently, the Harvard Business School published a paper they entitled “The IKEA effect: When labor leads to love”, referring to the furniture retailer. They found that “When people construct products themselves, from bookshelves to Build-a-Bears, they come to overvalue their (often poorly made) creations”.

You can read this research yourself: Harvard Business Review summary of IKEA effect or ready the full IKEA Effect paper.

I’m not suggesting that frameworks are poorly made. On the contrary, some of them are very mature, show great insight and can save the developer many hours of work and greatly improve the end results of his efforts. What does concern me at times is the quasi-religious adoration some developers afford a particular framework. Before becoming a satellite to a framework, a developer should ask whether it’s a fit for the problem he has in front of him.

Much of the same reasoning applies to discussion of programming languages. Expertise in one language should not rule out other language possibilities if a new problem justifies a new approach.

Do I have to use a framework?

One might ask if it is necessary at all to use a framework. Martin Fowler has encouraged the use of plain old java objects (POJO) for business logic. Rod Johnson’s efforts have the objective of reducing coupling with a framework.

The purpose of the framework is to provide an abstraction for lower level libraries. This often includes scaffolding necessary to perform some common or frequent tasks. Everything that you can do in the framework can also be done directly in plain Java code, but the framework may save you time.

For example, Hibernate may make access to a datastore more object friendly. Spring may make integration more descriptive. GWT can both accelerate the development life cycle for rich web clients and at the same time reduce risk in deployment with Java compile time checks and cross browser issues taken care of.

The complexity of the problem I’m trying to solve will often determine whether or not I use a framework, and which framework might be a fit. If my application will have very little javascript then I probably don’t need GWT (or even jQuery). If there will be very few interface pages and session management is minimal then I probably don’t need Wicket. There are cases when jsp pages with simple includes are more than adequate and even more appropriate.

More on frameworks

I really liked this presentation I came across while looking into frameworks http://www.slideshare.net/mraible/comparing-flex-grails-gwt-seam-struts-2-and-wicket-presentation

Framework choice for WordPress plugin licensing

The focus of the current project is to create an easy to use RESTful API that will enable license generation and verification. That means there is very little Javascript and so GWT seems a poor fit. At this stage I’ve also eliminated Seam and Flex for Java.

Since Google App Engine for Java is the target for initial deployment, I did a review of many of the popular remaining popular frameworks available to see how well they play with GAE. In some cases, this might be a good time to reevaluate the choice of GAE and possibly lean toward Amazon EC2 if there were a compelling reason to choose a framework that didn’t perform as well on GAE.

The most interesting frameworks are wicket and Spring, but due to the low complexity and native support the first iteration of my application will use basic servlets and jsp.