Now I could see it getting tricky if you have multiple build machines, but it seems like that would be pretty easy to handle as well by using different config files for different machines, or something similar. That might violate the DRY principle, so it would be good to think a little more about it. How do others deal with this?

This is particularly exciting because now it can be included in continuous integration setups.

One natural next step would be to set a threshold value so that crap4j would throw an error that would fail the build. I would be curious to hear comments on how people would like that to work.

Anyway, find out how to get the latest version at the blog.

A new version of crap4j has been uploaded to it's new home at http://www.crap4j.org/!

Please check it out and give us your feedback!

I might also show off the new crap4j tool that we have been working on lately.

I also set up a topic proposal for the JavaCamp, unconference that is happening Tuesday and Wednesday nights, on Adding JUnit to the Java Platform.

Here's the blurb for anyone interested:

Many language platforms, like Ruby and Microsoft .NET ship with a unit testing framework as part of the platform. Why not include JUnit in the Java Platform, or at least include it in the JDK? Code quality is a constant sore spot for commercial applications, so it seems like making the tools that contribute to higher quality more widely available will encourage better code. While we're at it, lets put in a code coverage tool as well, so we can see how well we're testing. We already have some profiling and management tools built in, so this seems like a missing piece of the puzzle.

I'd like to discuss this idea, and concerns around improving code quality with developer testing in general.

Here are the details:

To Catch a Bug, You Have to Think Like a Bug

"Again from Kuhn:

"The older schools gradually disappear. In part their disappearance is caused by their members’ conversion to the new paradigm. But there are always some men who cling to one or another of the older views, and they are simply read out of the profession, which thereafter ignores their work."

In computing, there is no mechanism for reading such men out of the profession. I suspect they mainly become managers of software development. "

The comments on the entry are enlightening. One comments that this could slow down garbage collection. Another comments that they always make sure that any code in their library that has system resource handles manages the closing of that code. I have used this approach in the past, but it was somewhat ugly.

For the talk about plugin writing, you can download the slides here

Read the original blog entry