I spend a lot of time on the web watching for useful stuff because I believe that knowing about some of it ultimately saves me more time than it costs me to keep up to date on what’s new. Among the things I found are projects which, in my opinion and mine alone, don’t get much respect, mention, or recognition. Hence, here’s my top ten list of projects which I’ve mentioned to people and gotten a, “Huh, never heard of it,” in response.
If you’ve seen all ten of them, bravo for you, please don’t write me to ask, “How could you include _______! I use it all the time.” Instead just leave me a comment at the end including a project I left off the list which should have been included. Then maybe everybody will learn something.
My Top Ten Obscure Java Projects
- JiBX – In a sense, this is not that obscure. After all, there was a four part series of articles about JiBX on the IBM site. But where I think it seems to blend into the wallpaper is that there are a hundred different XML persistence mechanisms out there for Java. Every week you see a new one that somebody rolled for some project added to Freshmeat.net. But JiBX is different than any
other one out there I’ve seen, including popular ones like Castor and Digester, because it puts Java byte code directly into the classes themselves to perform conversion to and from XML. As a result, performance blows away anything else I’ve seen. If you have to convert large volumes of XML to Java objects or vice versa and do it at high speed, this is the ticket. However, if you need flexibility in parsing an existing XML format into Java objects I’d still have to give the nod to Digester, it seems to be
able to handle a lot of odd structure.
- Bean Scripting Framework – As hard as it is for me to believe that this is obscure, it really seems to be. What if I told you that for a couple of hours of your time you could
- the display tag library
– How many web based applications display tables? Yeah, pretty much all of them.
DisplayTag makes displaying a really really nice table easy. It handles alternating line highlighting, pagination, and altering the appearance of items in the table through the use of a simple table decorator class. This is a tag library that anyone who has to build web applications needs to have in the repertoire right along side the JSTL.
- Batik – I’ve extolled the virtues of Batik before in this weblog. You’ve got an vector graphic rendering library that can work at a huge range of scales. It handles standard XML Scalable Vector Graphics (SVG) format files and they have pretty much the same level of expressiveness as PostScript. It’s written entirely in Java and you can incorporate it
into your application. Wow. Simply wow.
- Anthill – When you want to start having automated builds for your application, Anthill is probably the easiest way to go. It allows you to take the already existing Ant build script you should already have for your application and make it run on a regular schedule. It can automatically notice when there are changes to your code within a CVS source repository, check out the latest version of the code, build it using Ant, and perform post processes like JUnit tests or moving build products to a directory for download. Best of all, when a build fails to compile or fails JUnit tests Anthill will let you know via email so you can fix the problem. I love the way Anthill is simply built on top of most projects already existing build process so it can often be implemented and running in a couple of hours. A commercial version is available that has more features than the open-source version if you need them.
- Lucene – An indexing and searching library you can embed into your application. I like the fact that it will let you distinguish between text that you need to be able to search upon but not necessarily store (e.g. the body of an HTML page) vs. something you want to both search on and store (e.g. the title of that web page).
- Velocity – A straightforward, easy to use boilerplate system where you can create textual template files and then fill in portions of the text with values you set. Perfect for sending out emails, generating HTML, SVG, XML, and who knows what else without having to write a bunch of parsing code to handle your own template formats. I’ve used this in two different projects now and both times I ended up pleased.
- Prevayler – Easily the most controversial entry in the list. After breaking out with grandiose claims of huge performance improvements over relational databases and SQL, many dismissed this storage technology. Personally, I think that’s a mistake. Prevayler is not for every program. It really only works if you can fit all of the data you are trying to persist in memory. If 32GB databases are your stock-in-trade, move along, it’s not for you. On the other hand, if you have just a few megabytes of data to store and it will easily fit in memory then this is a good way to add storage of that data, have high speed access, and continue using internal data structures like Lists, Maps, etc. that you may already have rather than being forced to map to RDBMS table structures.
- Picocontainer – This is one of the lesser known of the newly popular “Inversion of Control” (IOC) or “Dependency Injection” containers. Spring is probably the best known of these type of object containers. Picocontainer is just an extremely lightweight container for putting a bunch of Java objects together and having each one get the other objects it needs in order to perform its functions. In many Java applications this is accomplished by hard wired code at the start of the program that creates each object and then passes references to other objects. Or worse, each object is left to its own devices and is allowed to get its own references to other objects or create them and the result tends to be very untestable code with a lot of dependencies. With Picocontainer the constructors on the objects specify the other objects they need and/or a set of interfaces for which they need object that implement those interfaces. The container is responsible for creating objects, doing so in the correct order, and connecting them up to satisfy those requirements. Spring is more flexible and powerful, but also significantly larger than the ~50K weight of Pico.
- Apache XML-RPC – SOAP is all well and good for making function calls over the Internet. It is interoperable across languages, implementations, yadda yadda. It’s also overkill for 80% of what most developers want to do (i.e. make a couple of simple calls to remote websites). XML-RPC is a much simpler XML format that is perfect for this and I can guarantee you that you’ll be able to create servers which can be called from many more languages than an SOAP service simply because just about any language you can find has an XML-RPC implementation. SOAP’s complexity ensures that many more obscure scripting languages have no client side implementation. Also, the simplicity in implementation carries over into simplicity of use. You could build both a simple server and client within an hour of picking up the library.