Criticisms of Web4j, Spring, PHP, and Rails

The most common of all follies is to believe passionately in the palpably not true. It is the chief occupation of mankind.
- H. L. Mencken

Web4j

All tools have drawbacks and trade-offs.

How many times have you become disillusioned with a tool, but only after you have invested a lot of time and effort in it? The purpose of this section is to make sure that doesn't happen to you with WEB4J, by listing items you should know about.

Tools that don't make an effort to clearly state their own drawbacks and trade-offs up front don't have your best interests in mind. Clearly, what they have in mind is their best interests, not yours.

WEB4J's philosophy is one of deep minimalism. Thus, WEB4J may not include things which you might feel should be there:

You May Need Third Party Tools

WEB4J doesn't depend on any third party tools or jars other than those published by Oracle and expected in a servlet environment (Servlet API, JSP/JSTL). Thus, adding third party tools to your WEB4J application may well be necessary. Examples of tools you might have to add:

TaskExample Tool
Javascript LibrariesjQuery
JSON parsing/formattingjson.org
Captcha toolRecaptcha
Charting JFreeChart, Google Charts
File Upload (before Servlet 3.0) Commons FileUpload
PDF Generation iText
Microsoft File Formats Apache POI

The toString, equals, and hashCode Methods Have Some Repetition

WEB4J provides good tools for implementing toString, equals, and hashCode. For each Model Object, the implementations of these methods vary in details, but their general technique or style is always the same. It would be very satisfying if these "general techniques" could be defined in one place.

There doesn't seem to be a satisfactory way of doing this with standard techniques of object programming. You may want to try and remove that repetition by using aspect programming tools such as AspectJ. Using JDK 5 annotations may be another option.

Backwards Compatibility Issues

We apologize for making occasional changes that are not backwards compatible. Such changes occur only when deemed necessary for the long term quality of the tool, in the direction of increasing elegance and simplicity. Such changes are never large scale, but it doesn't take much to break backwards compatibility. If you need to update an existing WEB4J app to a new version of web4j.jar, you may need to perform some migrations to the new way of doing things, using the Version History to find items that may affect you. Such migrations are almost always fairly minor, and there's never been a major rewrite of web4j. Its core ideas have remained intact from the beginning.

You should evaluate the recent Version History to see if you are comfortable with the size and frequency of such changes.

It's true that there isn't much positive to say about such changes, except for this: it allows the tool to remain aggressively minimalistic, and increases its overall elegance.

"There's a natural law in programming language and API design : as backwards compatibility increases, elegance decreases."
- Bill Venners, Artima.com
Given the minimalist philosophy of WEB4J, it seems appropriate to trade some backwards compatibility problems for increased elegance and simplicity. Some will not be comfortable with this.

Spring/Spring MVC

The Spring Framework is popular. It has also met with a disturbing lack of criticism, aside from some interesting comments by Bob Lee.

The following remarks are based on Spring 2.0. (Note: of course, Spring itself isn't a web application framework - Spring MVC is. However, when building a Spring MVC app, Spring is necessarily involved, so discussion of Spring itself is relevant in this context.)

Spring is huge.

The unzipped distribution is over 150 Meg. Spring is not a single framework. Rather, it's more of a collection of independent tools, with its Dependency Injection framework as the core item, Spring MVC as its web framework, and many other tools besides.

Some immediate consequences of this large size:

Spring is very fond of describing itself as lightweight. However, not many programmers would characterize a tool having more than 2400 classes, 82 dependencies on external jars, and a distribution size of 150 Meg as lightweight. This stretches the usual meaning of the term beyond its comfortable limits.

Spring has many bad names for things.

In designing an API, the importance of proper names cannot be underestimated. A good name will communicate clearly the purpose or general idea behind an item. A bad name causes the reader to feel confused.

Spring has many bad names. Some examples:

Name Context Why This Is A Bad Name
singleton scoping These items aren't singletons in the commonly accepted sense of the word.
abstract scoping Has two meanings, one of which doesn't refer to an abstract type.
set/list wiring These items don't necessarily correspond to the familiar Set and List.
Spring MVC web This the name of the web app framework, but you would never know it from the name.
global-session scoping Refers to portals, but doesn't mention portal in any way
command web Refers to objects that hold request parameters. Command is usually reserved for action classes, not data-related classes.
RequestContext web This refers to request parameters. In web apps, context refers to the application context, not request params.
AccessDecisionManager security Performs authorization. Name unclear.
ProviderManager security Performs authentication. Name unclear.
ThrowawayController web Refers to the fact that the object can be garbage collected after use. From the point of view of the caller, this detail is irrelevant.
bean wiring These items aren't actually Java Beans, since they don't need to conform to the Java Bean Specification (no-arg constructors aren't required).

The prevalence of bad names in Spring is unfortunate.

Spring apps need a lot of XML.

Spring applications often use large amounts of XML. In typical Spring documentation, about half of the examples are in XML, not in Java. The example applications provided with Spring show that XML files specific to Spring are on average about 24% of the size of your Java files:

App Lines XML Lines Java XML as % of Java
Pet Clinic 913 2,945 31%
Pet Portal 318 1,431 22%
JPetstore 693 3,512 20%
Average     24%

Anyone considering Spring should be aware that they will be spending a significant amount of time coding in XML.

Moving application development from Java to XML has many significant drawbacks for the typical developer:

Spring confuses coding with configuration.

As noted above, Spring apps contain significant amounts of XML. Thus, programmers spend a lot of time editing XML files when building their application. In other words, they spend a lot of time coding in XML.

Spring documentation refuses to acknowledge this fact. Instead, coding in XML is always referred to as "configuration". But this is both erroneous and egregiously misleading. For apparent marketing reasons, Spring wants you to think using XML is somehow inherently beneficial to your application. That is, since they are "only configuration files", they must therefore carry less burden or effort than regular coding. (Given the difficulties mentioned above, however, one could strongly argue that XML files require more effort, not less.)

However, if you are building an application, then you are coding. Configuration is applied to applications that have already been built and deployed. It's inaccurate and downright misleading to refer to any part of building an app as "configuration".

Here's a comparison of the typical meaning given to the word 'configuration', versus the meaning implied by Spring documentation:

Item Normal Config Spring "Config"
Number of files 1 N
Total number of lines small large
When settings made deploy time development time
File format simple text highly structured XML
Items interdependent usually not common
Usually small tweaks to behavior yes no
Specify class names rare common
Specify method names almost never common

Spring has too many parallel mechanisms.

Parallel mechanisms are different ways of doing more or less the same task. Instead of deciding on a single reasonable way of performing a task, there are often 2, 3, or even 4 variations on the same theme. This can be very frustrating, since you need to spend significant time, first understanding all the options, and then deciding which one to pick.

Examples:

Spring has many other issues as well.

PHP

Here are the major pitfalls and drawbacks of using PHP:

Rails

For the typical Java developer, here are the major pitfalls and drawbacks of using Ruby On Rails.

Rails doesn't do much to protect the application programmer from common security issues:

WEB4J does not suffer from the above security defects, since:

Rails has other issues as well.