The basic principle behind Jodd implementation is to make things as simple as possible, but no simpler. It is not an easy principle to follow, since adding new functionality and features to a system always brings more complexity within. Therefore, significant effort and refactoring is put to make every-day usage of Jodd utilities and frameworks understandable and natural.

Many programmers have a tendency to be Too Smart. Being Smart, they introduce various kinds of Magic into their software. This will usually lead to a software design that is more generic, dynamic and flexible than is needed, has more features than is needed, and is hence much more complex than is needed. Also, generally, complex solutions will be slower than simple counterparts, will be more prone to containing bugs, will be more difficult to debug, more difficult to maintain, more difficult to explain, and more difficult to learn. Which are, generally, bad things.

Jodd doesn't try to offer out-of-box solution that will solve 'all' problems, in all situations. Instead, Jodd tries to solve problems simple as possible, without adding too much complexity, but remaining open for such extensions. Such principle requires very, very good balance between usage complexity and functionality richness, which is not always easy to follow. Some would feel that some solutions are unfinished, but, this is often done by purpose, leaving users possibility to extend and fine-tune functionality in their own way, using common OO mechanisms.

Jodd is a vibrant library. It changes over time. Although most of code is stable, there is no doubt some classes will be changed, moved, refactored or even deleted for good. If some code requires refactoring, it will be done, no matter what, even if that means losing compatibility. Sorry for that, but we simply want the best code possible, no matter what, until we reach significantly rich release.