Jess 7.0b2 came out today! We're getting closer to a final release of "Charlemagne", Jess 7, "The Rule Engine for Real Programmers." I've been working hard on dividing the story backlog into the small pile of remaining things going into this release, and the things to save for 7.1.

There are a number of neat new features in this release, but the biggest, most visible change is the manual, which has undergone a massive cleanup. I actually redid many of the tools I use to create the manual to make the writing process easier. Besides many new sections and cleanups in the manual proper, I made a sweep through all the public classes in the library and cleaned up the Javadoc. I even added package summary files!

We just published a new edition of the JavaRanch Journal. It's the first one in a while, and the first one for which I served as the editor. The staff at JavaRanch are a smart bunch of folks, and they produced some great content for this relaunch. Enjoy!

In doing some code reviews on an existing project, I discovered instances of an antipattern that I've never seen described before. I'll talk about it here, but if anybody knows a reference for a similar discussion, I'd love to know about it. Thanks.

To use the Java testing framework JUnit, you can simply extend the TestCase class and add no-argument methods named testXXX(). JUnit will find these methods using reflection and execute them.

It's fairly common to create subclasses of TestCase to contain project-specific fixtures and utilities. You can then extend your subclass, add test methods, and have convenient access to those utilities. This is a perfectly fine practice.

Somtimes, though, in the course of development, you might see an existing test case class (call it TestFoo) with some useful setup code and be tempted to extend that test case with a new test case TestBar. This is, as it turns out, a bad idea, because TestBar will contain not only the utilities you inherit from TestFoo and the test methods you add, but the test methods you inherit from TestFoo as well! If you run all the test classes in a project, you might not notice that the test methods in TestFoo are being executed twice. If this happens often, the runtime of your test suite might suffer! For some reason, this behavior of JUnit, while it sounds obvious now that I've said it, isn't necessarily intuitive to junior programmers.

It occurs to me that there's an easy way to prevent this from happening: make it a rule that concrete test case classes must be final. This would prevent you from extending the class, and remind you to factor out the common utilities into an abstract test base class. So my question is: can anyone think of a reason why this would not be a good practice? I'm going to try this out in real life and see what happens.