Last Updates | Login      

Simplicity + Joy = Productivity

Thank you for taking the time to read this book. We understand that your time is precious and that if you want to take the chance of learning yet another Java web framework we better make good use of your time. That's one of the main differences of Mentawai when compared to other frameworks. Its main and ultimate goal is to save your time. It can only accomplish this goal by being as simple as it can be. If it is something very powerful, but complex, like the C++ language for example it will fail. Whoever has programmed in C++, and it is not a guru, will understand what I am talking about: C++ is tricky to get it right. C++ will get in the way of your projects and you will end up spending most of your time fighting with the language instead of getting the work done. Too much power generates complexity which in turn hurts productivity. When I started the Mentawai Web Project I had a very strong principle in mind: KISS (Keep It Simple, Stupid). In my opinion this is the most important principle and design goal of any software project. From the Wikipedia:

Wikipedia - KISS:
The KISS principle (acronym for "Keep It Simple, Stupid") states that design simplicity should be a key goal and unnecessary complexity avoided. It serves as a useful principle in a wide array of disciplines, such as software development, animation, engineering, and strategic planning.

But how do you measure simplicity? If you take a C++ guru and ask him if he considers C++ to be simpler than Java he will probably answer yes. He will say that there is nothing more trivial than memory management, pointers, references, structs, templates, etc. Nobody can say that he is lying. C++ is very simple for him. However in order to be fair when comparing the simplicity of two different languages or frameworks we must take the opinion of someone who has no experience with both languages or frameworks. If we take someone coming from Pascal that has never programmed in C++ and Java before, let him play with both languages for a couple of hours (or days) and after that he comes up with the conclusion that C++ is simpler than Java then I will be forced to think that he is lying or that he does not know anything about programming, abstraction and simplicity.

We also realized early that for Mentawai to acquire high levels of productivity it must be joyful. It must be fun. It must not be boring. And we have a very good example of a big Java failure that probably sent many people to a different career other than programming: Enterprise Java Beans (EJB). EJB (EJB1 and EJB2) was everything but joyful. I am proud of myself for not having to write a single EJB project in my life. Huge XML deployment descriptors, many different classes to do a single thing, many tricks that you must know or nothing will work, crazy integration with non-sense application servers (some costing thousands per CPU) and you have a recipe for a Rube Goldberg Machine. From the Wikipedia:

Wikipedia - Rube Goldberg Machine:
A Rube Goldberg machine is a fabulously overengineered apparatus that humorously performs a very simple task in very indirect and convoluted fashion (thus absurdly violating the principle of parsimony).

The goal of a Rube Goldberg Machine such as EJB, besides making a programming careers very boring and painful, is to kill the KISS principle. Most Java web frameworks are not as bad as EJB (that would be a very hard goal to accomplish), but we felt that they have abandoned the KISS principle. The rise of the Ruby on Rails framework (web framework designed with the Ruby language) had signaled to the Java community that something was wrong. Mentawai comes in the way to rescue the KISS principle and the joy of writing web applications in Java before everybody has moved to Ruby.

Ok, enough talk. Let me tell you why we think Mentawai is simple and joyful.

Mentawai Approach

So the Mentawai mission was already stated in the previous chapter:

Mentawai Mission:
To be as simple as possible, as joyful as possible, to stay out of the way of the programmer, boosting his productivity!

The Mentawai philosophy and approach to accomplish its mission is:

Programmatic Configuration: Mentawai uses Convention Over Configuration but whenever you need or want to configure your controller, your filters, your validation, your IoC, your AutoWiring, etc. you will use a configuration file written in Java. You will NOT use annotations and you will NOT use XML. Back in 2005 when Mentawai was born, frameworks like Struts were abusing the use o XML, taking away the joy of programming. XML programming is definitely not cool. Annotations programming is not cool either. In 2004 Martin Fowler wrote the following about configuration:

Martin Fowler:
A separate but often conflated issue is whether to use configuration files or code on an API to wire up services. For most applications that are likely to be deployed in many places, a separate configuration file usually makes most sense. Almost all the time this will be an XML file, and this makes sense. However there are cases where it's easier to use program code to do the assembly. One case is where you have a simple application that's not got a lot of deployment variation. In this case a bit of code can be clearer than separate XML file.
I often think that people are over-eager to define configuration files. Often a programming language makes a straightforward and powerful configuration mechanism. Modern languages can easily compile small assemblers that can be used to assemble plugins for larger systems. If compilation is a pain, then there are scripting languages that can work well also.
One thing we're seeing in the Java world at the moment is a cacophony of configuration files, where every component has its own configuration files which are different to everyone else's. If you use a dozen of these components, you can easily end up with a dozen configuration files to keep in sync.
My advice here is to always provide a way to do all configuration easily with a programmatic interface, and then treat a separate configuration file as an optional feature.


The separate and independent configuration file in a Mentawai web project is called ApplicationManager. You can call it anything as long as it inherits from org.mentawai.core.ApplicationManager. Below is a simple example of an ApplicationManager:

Or you can use the less verbose versions of the methods:

Shortly after the first stable version of the Mentawai framework was released, I wrote an article for the JavaWorld site emphasizing the need to avoid the XML bloat. Although at that time a lot of people were defending the XML approach, it became very clear to us that the programmatic approach had many advantages:

Less likely to contain errors or typos because it is compiled before it is loaded by the web application.

Great IDE integration so that you can take advantage of code-completion, auto-compile, refactoring, inline documentation, etc.

Great flexibility that only a programming language can offer so that you can use loops, ifs, methods, objects, etc., in other words, you make the configuration adapt to yourself and not the other way around.

Ability to optionally use a dynamic scripting language such as BeanShell, Groovy, JRuby, etc. so that you can accomplish true dynamic configuration, in other words, changes in the configuration are automatically reloaded by the application without the need to restart the application.

The good and old JavaDoc to document your configuration methods and classes.

More important than the advantages above is that programmatic configuration is more natural and joyful because we are talking about Java code and not another XML specification. XML is a markup language (not a programming language) designed to provide a platform independent representation of data. Unfortunately, in our opinion, people have taken its usage too far. For an example let's take a look on how Struts2 uses XML to do validation:


Besides this boring and unnatural XML schema you should notice that it is actually mixing Java code with XML code. Some people may say "Who cares?" but our opinion is that this is not joyful or natural. A quick look around the Internet will reveal some more exotic things people are doing with XML.

OpenXava (

OpenXava Site:
OpenXava is a framework to develop easily business applications with XML and Java. Its virtue resides in the fact that the heart of our applications is XML instead of Java.


IBM Article:
The Xalan XSLT processor can invoke almost any method in almost any Java? class in the classpath.

Please note that we have nothing against these projects and that they surely have their scenarios, but we believe that XML Programming is definitely not the way to go for agile and joyful web development. The Mentawai approach since its inception was to eliminate all XML and perform any kind of configuration/setup using the Java programming language.

No Annotations: Although Annotations is a great improvement when compared to XML, its usage can also be taken to bad extremes. Plus when you annotate your code all over the place you are really scattering the configuration throughout your code. It is very likely that any change in your configuration will force a full rebuild of your application. Note that because a Mentawai web project makes use of a separate and independent Java class, any change in your configuration will not require a full rebuild. You can change, compile and redeploy just your configuration many times while your main application has not changed. You can even have different configuration files (different ApplicationManagers) that can be applied to the same web application.

Another drawback of annotations is that it will tie your code to the framework being used, in other words, any further compilation of your code will require the framework jar in the classpath. Maybe not a big deal for your actions, but definitely not something recommended for your business model. With the Mentawai approach of having a single centralized Java class for the configuration, this will never happen, in other words, your web application can be totally decoupled from the web framework.

Coming back to the issue of annotation abuse here is how Struts2 use annotations to perform validation:


We believe that Annotations Programming can be as bad as XML Programming, therefore, to avoid this pitfall and to be different from the majority of web frameworks out there, Mentawai has decided to abolish any kind of annotation. The goal is to keep it clean and keep it simple without annotations, the only exception being @Override.

Full-stack: To do a web project before Mentawai was very easy, provided that you knew how to use and integrate close to 10 different Java frameworks. You can use Struts for the controller, JSTL for the JSPs, Hibernate for the persistence solution, C3P0 for the connection pool, Commons Validation for the validation, Spring for Inversion of Control and Auto-wiring, Commons Email for sending emails, Commons File Upload for uploading files, JAAS for authentication and authorization and perharps Tiles for templates, Log4J for logging and OSCache for caching. Everybody will probably agree that this is a Rube Goldberg machine very intimidating for newcomers. But this can be avoided with the abstraction power of any object-oriented programming language. The Mentawai approach is to use high levels of abstraction to shield all this complexity from the web developer. Some of these frameworks were actually incorporated by Mentawai so you don't need to know them to use them. You can start a Connection Pool, something very basic for all web applications, with two lines of code in the ApplicationManager. Under the hood Mentawai will setup and use a C3P0 connection pool for you. Same thing for sending emails. You don't need to know Commons Email to send an email message. You can just use some simple lines of code to send emails from Mentawai and under the hood it will use the Commons Email framework for you. For other features like Authentication, Inversion of Control, validation, etc. Mentawai implements its own simple and high level solution, so you can take advantage of them without having to bring a whole new framework into play. Although the Mentawai goal is to be a full-stack solution for web applications, it also offers integration with other frameworks such as Spring, Velocity, JSTL, Hibernate, etc.

Allow me to talk a little bit more about abstraction. With the rise of the Ruby programming language, which I like very much, Java was blamed of being a no pragmatic language and a very verbose language. If you compare Java with Ruby this statement is correct. No question about it. Let's take a look of how Java opens up a file to count its number of characters and how the same program could be done in Ruby.

Now the Ruby version:

Wow! At a first glance it really looks that Ruby is much more pragmatic and less verbose than Java. And it really is. However, with some abstraction power, we can solve this problem and put Java back in the game.

What we did was abstract the complexity inside another object called FileUtils. Some Ruby lovers will complain that we cheated, but now to count the chars of a file in Java has become very easy and pragmatic. That's exactly what the Mentawai framework tries to do for web development. The Mentawai approach is to abstract all the complexity so that the recurrent tasks of every web application become easy and straightforward every time you start a new project.

Convention over Configuration: This approach should be taken for granted by any framework that wants to be simple and productive. Mentawai uses Convention over Configuration (CoC) in many situations and you can even create your own conventions to override Mentawai's one. To have Convention over Configuration means to have defaults for everything and allow the user to change them through configurations.

Some examples of CoC in the Mentawai framework are the directories where the internationalization (i18n) files are located and the location of the JSP files for an action to which no consequence was specified. For example if you have coded a validation filter with the name, the convention for the i18n file location is: /validation/UserValidation_locale.i18n. If you have the action add() inside the class the convention for the JSP file location is: /UserAction/add.jsp. Of course you can change these conventions with simple configuration methods, but only if you need or want to. And as we have already seen, when you want to escape from the Mentawai conventions you will use programmatic configuration to do so.


In this chapter we talked mainly about the Mentawai mission, philosophy and approach. We learned that the Mentawai mission is to be as simple as possible, joyful and productive. This is a very important statement that the Mentawai team keeps in mind on each and every modification of the framework, so allow us to emphasize this phrase.

Mentawai Mission:
The Mentawai mission is to be a web framework as simple as possible, joyful and productive.

To accomplish that mission, the Mentawai framework has a very particular philosophy and approach. It uses Programmatic Configuration to make the art of programming more joyful and to escape from the XML/Annotation bloat. As we have seen, a programmatic configuration has many advantages over a configuration done through a markup language such as XML, among them integration with IDE, javadoc, dynamic scripting language configuration, flexibility, compile-time errors, etc.

Mentawai Approach:
To use Programmatic Configuration and avoid any kind of XML and Annotations.

Another key point from the Mentawai philosophy is the use of high levels of abstraction to shield as much complexity as possible from the programmer and to escape from the Java framework salad. Mentawai believes that in order to do a web project in Java you should need as few frameworks as possible.

Mentawai Approach:
To use high levels of abstraction to shield as much complexity as possible from the programmer.

Mentawai Approach:
Avoid the Java framework salad by incorporating other frameworks (respecting their license of course) and implementing the main functionalities of other frameworks in the Mentawai core.

And last but not least, the use of Convention over Configuration (CoC) to provide defaults for all features.

Mentawai Approach:
To use Convention Over Configuration to provide defaults for all features allowing the programmer to change them through programmatic configuration.

Enough of boring theory. Let's get some action now!