Talk Nerdy To Me

A great Open Source project for gaining understanding about e-mail systems, including an in-depth look at SMTP and POP3, is the Java-based Apache JAMES Project.  Although JAMES has the unfortunate shortcoming of being built around the now defunct and unsupported Apache Avalon Framework, it’s still a fantastic learning tool for understanding email protocols, mail delivery, and spam filtering.  Not only that, it’s a fully functional, enterprise-ready mail server that can be up and running with minimal configuration.

One technology implemented by JAMES for spam filtering is real-time DNS blacklists.  DNSBLs identify the IP addresses of potential spam sources and machines known to be delivering spam (as determined by the sometimes controversial policies of the list owner).  Spam blacklists date back to 1996 with Paul Vixie’s Mail Abuse Prevention System, and are now used by ISPs and corporate mail systems around the world.  Countless organizations maintain blacklists, and Web sites like MX Toolbox permit ad hoc queries of IP addresses against dozens of published lists.

(more…)

JUnit Factory is rather clever how it analyzes and executes your code to generate characterization tests. However, legacy Java code was generally not written with testability in mind. This sometimes makes it difficult for JUnit Factory to attain complete coverage of your code due to the need for objects to exist in a complex state or the need to interact with an external resource such as a database.

JUnit Factory is often able to generate mock instances automatically for problematic classes. When automocking fails, the developer can improve coverage by either extracting behaviors into private methods or by providing hints to JUnit Factory in the form of test data helpers.

(more…)

Characterization tests provide a safety net for your legacy Java code by helping identify unintended changes in software behavior caused by code maintenance. JUnit Factory from Agitar Software may be used to automatically generate these tests for you. In this post, we’ll take a look at what happens to these characterization tests when a simple code change is made.

(more…)

JUnit Factory is a free Eclipse plug-in from Agitar Software that generates characterization tests for your Java code. For more background on what characterization tests are, and how you use them, you’ll want read my post “Characterization Tests: How To Deal With Legacy Java Code”.

This article describes how to generate tests for a simple Java class and how to read the tests. Not all of your real code will be this simple, and not all generated tests will be this simple, either. But, bear with me as we start small and work our way up.

(more…)

Companies have invested billions of dollars over the last decade building components and applications based on the Java framework. This work represents a wealth of expertise and collective knowledge that firms must protect and maintain. Unfortunately, in the dynamic field of software development where programmers change jobs, on average, every 18 months, the original developers on these past projects probably aren’t around anymore.

As a result, Java developers seldom have the luxury of working on true greenfield projects. Instead, they are faced with adding enhancements and fixing bugs on projects built upon a code base they didn’t write and don’t fully understand. How can developers safely make changes to legacy code without accidentally breaking something unrelated?

Characterization tests provide a safety net – a change detection engine – that identifies behavioral changes in legacy code in order to remedy regressions early in the development process. Fixing regressions early shortens development timelines, increases code quality, and allows a team to become more agile. You can automatically generate your team’s characterization tests using the free JUnit Factory for Java from Agitar Software.

(more…)

Vincenty’s Formula is an iterative solution for calculating the distance and direction between two points along the surface of Earth. For clarity, I’ve stripped out portions of the code I’ve put up for discussion, but you can download the entire Java source code from here. If you prefer C#, please see the C# version of this discussion.

Several years ago, I stumbled on a great pastime called “geocaching.” It’s a worldwide treasure hunting game where participants use handheld GPS receivers to find hidden “caches” - small boxes filled with prizes, trinkets, and “travel bugs“. The caches are hidden by other participants who post nothing more than the latitude and longitude on a website like Geocaching.com. My children and I have had a blast. It’s a great way for a grown man to justify playing in the woods (and buying an expensive gadget!) under the pretense of “playing with the kids.” With over 420,000 caches in 222 countries on all continents (including Antarctica!) there are bound to be several near you.

(more…)

Roundoff problems have been the bane of programmers since computers started handling floating point numbers. Floating point numbers are represented by a finite number of bytes. This limits the precision of numbers that may be represented - you only get so many significant digits. More subtly, however, finite length floating point numbers limit which numbers may be represented accurately. Repeating decimals (which, in a sense, require an infinite number of significant digits) cannot be represented precisely. You may only store the nearest value representable by the computer. This is the origin of annoying roundoff problems found in floating point arithmetic.

The C# and Java 4-byte float data type provides 7 significant digits of precision, while the 8-byte double type provides 15. Using the higher precision double data type helps minimize the roundoff error, but it must still be addressed.

So, when I encountered the C# 12-byte decimal data type with its 28 significant digits, and Java’s arbitrary size BigDecimal data type, I figured these were simply ways of further minimizing the problem with a wider floating point type. Only after digging deeper did I realize that the implementation behind both of these data types is a stroke of genius.

(more…)

I have to admit, when I first heard about the open source project Crap4j, I thought it was a joke. It sounded like a sarcastic, tongue-in-check spoof on the masses of brittle legacy Java code accumulating daily in software development shops around the world.

It isn’t a joke.

The Crap4j Web site describes the Change Risk Analysis and Predictions software metric as “a mildly offensive metric name to help protect you from truly offensive code.” Well said. The levity of the name belies the seriousness of the problem. Java is no longer a new language. Greenfield development has made way for maintenance and incremental upgrades to massive legacy code bases for which the original development team is long gone.

We all know legacy Java code is often poorly documented, but dig a little deeper and you’ll discover something even worse: it’s poorly tested! Now, consider that legions of developers have added little tweaks and bug fixes along the way without giving consideration to meaningful refactoring. What else can you do but throw up your hands (or your lunch) and declare “This code is crap!”

(more…)