Alex Collins is a enterprise Java developer and currently works in the UK. He has worked in the insurance, publishing, telecoms and supply chain. In his spare time he codes in Python, Clojure and Scala (but not at the same time) and enjoys a multitude of sports. His catchphrase is K.I.S.S! Alex has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

5 Java powered open source tools for your team

  • submit to reddit

If you're a Java shop and want to ensure you can support your team's toolset, here are some pointers for the must-have tools we modern developers use day-to-day.


If you haven't got one yet, or keep thinking about it, go get a Wiki for your team. Having a place where knowledge can be quickly documented and shared instantly is a big plus as it allows you to hold knowledge in a central place for anyone to access instead of having to prize it out of your colleagues brain on a Monday morning. Also, when people leave your team, or you have to pick up a project from someone else you can get up and running should documentation be sufficient. It helps you avoid "single point of failures" in a team where only one person understands a portion of your codebase or systems overall.

  • VeryQuickWiki - a cheap and cheerful Wiki engine that works very well. Seems to be quite reliable too. From its homepage: "file- or database-based persistency, switchable parsers, virtual wikis, emailed change notifications and more."
  • JaWiki - requires no RDBMS and stores all information in XML files. It runs under Apache Tomcat and comes pre-packaged as a WAR
  • JamWiki - boasts an array of features that match Mediawiki and also doesn't require an RDBMS for storage. Quite a mature codebase too, certainly worth checking out!  


If you're honest you'd have to admit that you're also probably lazy; all programmers are. Sometimes ALT+Tabbing to an IM window and asking a question is easier than waltzing over to your colleague and, you know, talking to them. E-mail for some reason doesn't cut it; too...'bulky' and far too annoying if your inbox is full, or the exchange server is being hammered by Jane from HR forwarding chain-mails to her buddies.

  • Google Apps - this is an obvious one, but it offers a hell of a lot for free. You get IM (GTalk), Email (Gmail), calendar and Google docs for free and premium. Not strictly Java of course, but you'd not have to worry about hosting! Not strictly Java based or Open Source, but certainly worth a mention if only for the cost-saving benefits.
  • OpenFire - Java based and very professional looking collaboration framework, OpenFire as taken from the horses mouth is: "a real time collaboration (RTC) server licensed under the Open Source GPL. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance".
  • Tigase - this FOSS XMPP (Jabber) server boasts an impressive array of features such as scripting support, uses only 10MB RAM and 500k users on a single machine. Great if you want to IM amongst your team and have a spare box lieing around

Continuous Integration

CI is a funny one. It's one of these development approaches much like unit testing that only seems worth it after you've started using it. Its benefits are far reaching depending on what tools you employ in your team. If you've barely got a build process then CI can help solidify it. From then on, you've got a means of ensuring your code is kept in a consistent state, you can automate unit testing and even deployment. It's a great way of setting a standard and keeping it there. Most work by watching your projects in your SCM of choice and then automatically building the code after a full (or modified-only) check-out. Some are more sophisticated in this manner however.

  • Hudson - a popular choice, with easy configuration, strong support for Maven, Ant, as well as a miriad of SCM from Star Team to SVN. Packaged as a WAR, Hudson also comes packaged in a format for most major Linux distributions.
  • Continuum - from the Apache Software Foundation, Continuum holds functionality much the same as any other but has role-based authentication which in a large team could certainly become useful.
  • Cruise Control - another popular choice, yet plagued with heafty manual configuration in earlier versions, this is however a mature choice and something that shouldn't be overlooked.

Static Code Analysis

Static code analysis tools can assist in the extra-mile of reviewing code and ensuring a basic standard has been met. They work by analysing (duh) your codebase and comparing against pre-defined rules that are configured by yourself or as default profiles. Such tools can list problems from erroneous assignments in if statements to performance enhancements such as moving inner classes to statics for overhead reduction when creating new instances. If you want the perfect codebase, static analysis can certainly help.

  • Findbugs - developed by the University of Maryland, Findbugs is a simple bug powerful tool that'll integrate with Ant very well. It's also supports reporting in various formats. A quick win for its ease of use, great set of items for analysis and a mature codebase.
  • Sonar - this one's a bit bigger than just a static analysis tool as its features are so vast. As it put its so eloquently on its homepage, Sonar is an "open platform to manage code quality" and that's exactly what it does. From unit test coverage to findbug integration, as well as graphing for statistical analysis to see traits in your development - such as critical bugs introduced over a timeframe. Sonar can be backed by a MySQL backend should you need it. This one's certainly not for the hobbyist user. It has tight integration with Maven so can be plugged in to any phase quickly and easily

It's important to remember that tools are just one part of a team and can't cure sensible and well defined development practices. That said, there's much fun to be had and of course progress made with any of the tools mentioned in this article.


Published at DZone with permission of its author, Alex Collins.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Roger Lindsjö replied on Wed, 2010/09/08 - 5:27am

We went from a process where at the end of each project there could be several days of fixing bug before the system would be stable enough to start and test (as different components had diverged or interpreted requirements in different ways). We decided to try to have a system built and integrated automatically which at first met some resistance:

  • We can't build every week, that takes too much time that we instead could spend on developing features.
  • The system is too complex to build / install / start automatically, there are so many manual initialization steps.

Some of us questioned this and asked if all of these manual steps were different each time. Of course they were not so we requested scripts for everything needed (we said that we start with "simple" scripts, no full CI system yet). Of course we noticed that it wasn't very hard, and now we build each component at every commit, the whole system is built and installed every 2 hours on a "latest" server, once a day these builds are also installed on a "stable" server if all automatic tests passes.

We are still wanting in the area of automatic tests, but now we can start testing periods whenever we want, all development can be tested in a fresh install after 2 hours and a "working" system is always available. This has made it much easier for developers to test their code and also being able to discuss it with product managers and customers.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.