Jodd is a generic purpose open-source Java library. It helps in development of Java applications, both stand-alone and server-side.
- Posted by: Dion Almaer
- Posted on: December 31 2003 10:27 EST
Jodd contains many useful and ready to use features: it provides Java beans manipulation, loads beans with ease from various sources, simplifies JDBC connectivity and code, profiles sql queries, manages date and time, manipulates and format Strings, searches files on disk, helps with handling servlet requests. Additionally, Jodd contains small, yet useful mvc2 JSP-based framework. And there is more inside...
Read details about Using Jodd
View the Jodd Home page
- Jodd: General Use Open Source Library reaches Stable 0.2 by Emmanuel Bourg on January 02 2004 09:20 EST
- Why Jodd? by Peter den Haan on January 02 2004 10:06 EST
- Not really needed by Les Hazlewood on January 04 2004 12:13 EST
- Jodd: General Use Open Source Library reaches Stable 0.2 by Vic Cekvenich on January 04 2004 12:53 EST
- just few notes... by Igor Spasic on January 05 2004 06:25 EST
Interesting but many features of Jodd are already covered by Jakarta Commons projects. I don't think the community needs another logging wrapper or another base 64 converter for example.
Ok. No-one else responds, so I will. I really would like to like Jodd, and it definitely makes some of the right noises. There's an emphasis on simplicity and leanness. It seems test-driven. An eye for performance is always good. But upon taking a closer look, I unfortunately fail to see its point completely.
What is the justification for yet another naive MVC implementation? Didn't we have enough of those already? If you don't like Struts -- and I couldn't blame you -- then there are a gazillion alternatives of all levels of sophistication and all kinds of approaches.
Taglibs -- great, but why reinvent the well-known JSP template taglib that you can find everywhere (including in Struts) and which has eventually evolved into the much richer Tiles library? Why the overlap with the JSTL?
And what's the raison d'etre of a simple SQL support class where much richer, more foolproof (template-based) JDBC libraries exist? (Spring!) And why is avoiding instanceof and casting in this class so important, given that they are several orders of magnitude faster than even the simplest database query? Why buy into a programmatic SQL profiler solution dependent on your SQL class if you can use completely generic, no programming required tools like P6Spy or IronEye?
Why another connection pool, and worse, an oldfashioned one that forces an explicit dependence of your code on the pool implementation? Why explicitly return connections rather than simply close() them? Because of the perceived object churn overhead?
Why yet another JavaBean library? Because Jodd is a bit faster? Is that enough? And what exactly made you indicate an error by returning false rather than throwing an exception? This seems a throwback to the old C days. How do I distinguish between a programming error and a property value that happens to be null?
I could go on. Jodd has a whole army of utility classes. They're by no means bad, but most of them have been done equally well or better elsewhere. Everywhere in the javadoc, reference is being made to the implementations' superior speed. I'm happy to accept this, but surely for a general-purpose library that is misguided optimisation: the last ounce of speed is rarely important, and in those rare cases where it is, it is important in only a tiny fraction of the code. Elsewhere, the criteria are robustness, good design, functionality, ease of use, those kinds of things. Those criteria Jodd does not address consistently enough to compete.
Why not contribute some of the worthwhile speedups to the Jakarta Commons and other existing projects, and then concentrate on something truly innovative and immaculately crafted? Jodd clearly betrays a bright mind. Use it.
Practically everything offered by Jodd is covered quite cleanly and in a sophistocated manner by Jakarta Commons (http://jakarta.apache.org/commons) and the Spring Framework (http://www.springframework.org).
Jakarta commons is well-known, well established, and has a large developer base which continues to drive innovation.
Spring is just plain awesome, unbelievably flexible and fills in most gaps in the Commons stuff (and its LGPL whereas Commons is Apache). Based on IoC (Inversion of Control), it doesn't require that your classes "know" about any Spring classes. Its MVC package alone is easier to use and more intuitive than Struts (and even integrates with Struts if you wish) and it has tons of utility classes/frameworks for JDBC, Hibernate, AOP, and more...
I'm not trying to crush Jodd's intent (which is perhaps to add more innovation to the Open Source community?). I think it would be better if the Jodd developers instead tried to contribute to Jakarta Commons, Spring, or both. Commons and Spring are so popular and accepted now and do everything that Jodd is trying to do...why not make those better instead of trying to reinvent the wheel?
I like it and I use it.
No where do you have this, not in jakarta commons for sure:
Java 1.6 needs improvments in date above,
Logging via jakarta-commons-logging
JDBC should use RowSet/DataSource (result set/connection should be deprecated)
Java 1.6 should split the client side java (awt, etc) to a seperate jar for the few people that use client side java.
FYI, a full alternative to Java dates and times is being developed at http://joda-time.sourceforge.net
let me try to explain the main purpose of jodd: it should be a handy library that may help in everyday java work. i've seen too many times that developers code the same functionality again and again and in most cases not correctly, even buggy. take for example simple string replacement: i've seen many variations and only few good ones. i believe that such every-day java problems and routines do have a single solution that is better (i.e. working, faster and easier to use) than others in most cases. therefore, jodd is meant to be a collection of such utilities that should help users to use existing java features in an easier way. i do know if this goal is achieved, it is not on me to judge.
additionally, among various utilities, jodd contains some extra stuff: a simple mvc solution and bean utilities. most of comments and critiques consider just these two parts of jodd - and they are all correct. jodd can not compete with existing frameworks such as spring or some existing bean utilities (at least, not yet:). mvc solution in jodd is built in believe that there has to be an much easier way to do mvc than struts. bean utils are built because i find some tiny differences from other libs - and i admit that this may not be enough reason for bean utils existence. at the end, jodd has been developed by a single person with modest knowledge, and you can not expect a complete framework from such resources:)
on the other hand, i find that users like and use some other parts of jodd that are generally not much discussed or reviewed (datetime, sqlutil, sprintf, misc utils etc). i need to answer on some of above issues regarding these parts:
+ taglibs: there are no jstl tags except one or two, that are kept for compatibility reasons. jodd do not provides taglib solution (jstl seems to be enough). other provided tags are for mentioned mvc solution and the include tag, that i wanted to work as m4 unix utility.
+ sqlutil is not a framework - it is a simple utility built over the jdbc classes and it significantly shorten the amount of code needed for jdbc. if you consider jdbc proved, jodds sqlutil is proved as well. it additionally may show params in prepared statements and has a simple profiling. once again, this is not a solution, it may just profile some query very quickly, without any settings and with minimal code change etc. sqlutil is not a solution how to work with db, but if you use jdbc/resultset/connection it may helps a lot. personally, i agree with Vic above (if hibernate is not around:) and there are some future plans for more enhancements.
+ connectionpool is an interface. its implementations are either adapters for some existing pools either pools itself. since there still exist pools that need to return the connection, this interface needs to have a close() method.
i hope that you got the picture what jodd is ment to be. please, i am not trying to convince anyone that jodd is a super-library. however, it is build with care, and if someone find something useful, great, if not, never mind. i hope that in time some useful stuff will be distilled from it.
and at the end, jodd is still 0.20:)