 |
|
|
|
|
|
Diagnosing Java Code: Recorders test for proper method invocation
In this installment of Diagnosing Java Code, Eric Allen describes how to use Recorders (a special type of Listener) in your unit tests to ensure that a sequence of method invocations occurs in the proper order.
|
|
Articles |
|
01 Jun 2001 |
|
| |
Diagnosing Java Code: The Dangling Composite bug pattern
One of the most commonly recurring (and most complained about) bugs in Java programming is the null-pointer exception. Tracking down the cause of one of these bugs can truly make you question your career decision. In this installment of Diagnosing Java Code, we'll continue with our examination of bug patterns by cataloging one of the most common patterns associated with null-pointer exceptions and step through an example of a class that contains it. We will then review several programming techniques that can help you minimize the pattern's occurrence.
|
|
Articles |
|
01 Mar 2001 |
|
| |
Diagnosing Java code: The future of software development
Eric Allen discusses some of the current trends in software development and predicts what they may lead to in the coming years.
|
|
Articles |
|
17 Jun 2003 |
|
| |
Diagnosing Java code: Java generics without the pain, Part 2
Eric Allen continues the discussion of generic types in JSR-14 and Tiger. He outlines several limitations imposed in those Java extensions and explains how the limitations are necessitated by the implementation strategy used by the compilers of these extended languages.
|
|
Articles |
|
11 Mar 2003 |
|
| |
Diagnosing Java code: Design for easy code maintenance
This month, Eric Allen explains how avoiding and controlling gratuitous mutation is key to retaining code robustness while making the code easier to maintain. He focuses on such concepts as functional style code crafting and ways of marking fields, methods, and classes to handle and prevent mutability. Also, Eric explains the role of unit testing and refactoring in this task, and offers two tools to aid in refactoring efforts.
|
|
Articles |
|
01 Jan 2003 |
|
| |
Diagnosing Java code: Assertions and temporal logic in Java programming
Although traditional assertions can increase the amount of checking that can be done over Java code, there are many checks you just can't perform with them. One way to fill this gap is with temporal logic, a formalism used to describe how a program state will change over time. In this article, Eric Allen discusses assertions, introduces temporal logic, and describes a tool for processing temporal logic assertions in your programs.
|
|
Articles |
|
01 Jul 2002 |
|
| |
Diagnosing Java code: The case for static types
Many popular languages -- such as Ruby, Python, and other so-called scripting languages -- have moved away from static type checking as a means to help improve the reliability of code. Still, static type checking can be one of the key weapons in a powerful arsenal against introducing and for detecting bugs. In this article, Eric Allen makes a case for static type checking, explains why we should be glad that the Java language supports it, and discusses how it can be made even better.
|
|
Articles |
|
01 Jun 2002 |
|
| |
Diagnosing Java Code: Platform-dependence "gotchas"
The JVM provides an unprecedented degree of cross-platform interoperability, but glitches at both the specification and implementation levels can keep programs from behaving on multiple platforms. In this article, Eric Allen discusses some platform-dependent aspects of Java programming to watch out for, and also demonstrates some ways around these dependencies.
|
|
Articles |
|
01 May 2002 |
|
| |
Diagnosing Java Code: The Run-on Initializer bug pattern
Often you see code that initializes a class not just by calling a constructor, but also through several follow-up actions intended to set various fields. Such follow-up actions, unfortunately, are hot spots for bugs, introducing a type of run-on initialization. In this installment of Diagnosing Java Code, Eric Allen explores the Run-on Initializer bug, discusses why and how it should be avoided, and demonstrates how to minimize the damage it may cause.
|
|
Articles |
|
01 Apr 2002 |
|
| |
Diagnosing Java Code: Repls provide interactive evaluation
Normally, when running a Java program, it's necessary to run the program from a main() method, passing in parameters with the String[] input argument. But when a program is still being debugged, this can be a cumbersome task. In this article, Eric Allen discusses the advantages of interactively evaluating the expressions and statements in your program, and offers some Java repls (read-eval-print-loop tools) that help you with this task.
|
|
Articles |
|
01 Mar 2002 |
|
| |
Diagnosing Java Code: Designing extensible applications, Part 1
In this and several upcoming installments of Diagnosing Java Code, Eric Allen focuses his discussion on considerations involved in determining how extensible a new system should be, when extensibility is best applied, and how extensibility relates to other factors, particularly testability. In this first article, he examines the various ways in which a software system may be extensible and in what contexts each form of extensibility is most useful.
|
|
Articles |
|
25 Sep 2001 |
|
| |
Diagnosing Java Code: Designing "testable" applications
In this installment of Diagnosing Java Code, Eric Allen takes a break from examining specific bug patterns and opts instead to discuss the issues involved in designing software that is easy, and even pleasurable, to test. He outlines seven design principles that can greatly increase your productivity in writing tests, and thereby improve the robustness of the resulting code base.
|
|
Articles |
|
01 Sep 2001 |
|
| |
Diagnosing Java Code: The Orphaned Thread bug pattern
In multithreaded code, it is often common to use a single, master thread that drives the actions the other threads take. This master thread may send messages, often by placing them on a queue, that are then processed by the other threads. But if the master thread throws an exception, the remaining threads may continue to run, awaiting more input to the queue, causing the program to freeze. In this installment of Diagnosing Java Code, full-time Java developer and part-time exterminator Eric Allen discusses detecting, fixing, and avoiding this bug pattern.
|
|
Articles |
|
01 Aug 2001 |
|
| |
Diagnosing Java Code: The Fictitious Implementation bug pattern, Part 2
In the last installment of Diagnosing Java Code, we saw that it is possible to implement a Java interface without actually meeting its intended semantics. This second article in a two-part series demonstrates two handy tools to fight such false implementation bugs. Eric Allen shows you how to use assertions and unit tests as executable documentation, making your code safer and more portable.
|
|
Articles |
|
14 Aug 2001 |
|
| |
Diagnosing Java Code: The Fictitious Implementation bug pattern, Part 1
The Java language is free from many of the problems endemic to languages that support multiple inheritance -- in part because it restricts the specification of interface invariants to type signatures. But that restriction can combine with poor documentation to create problems: if you make incorrect assumptions about how an interface will be implemented, you may encounter frustrating bugs at run time. This article, first in a two-part series, outlines the development practices that can lead to such errors -- and ways to avoid them.
|
|
Articles |
|
31 Jul 2001 |
|
| |
Diagnosing Java code: The Split Cleaner bug pattern
One of the features of the Java programming language is that storage is automatically managed, saving the programmer from the bug-prone task of freeing memory after it has been used. Nevertheless, many programs still have to manipulate resources, such as files and database connections, that must be explicitly freed after use. Like manual storage management, there are many pitfalls when managing resources in this way. One of these pitfalls is the topic of this week's column -- the Split Cleaner bug pattern.
|
|
Articles |
|
01 Jul 2001 |
|
| |
Diagnosing Java Code: The Impostor Type bug pattern
In this installment of Diagnosing Java Code, Eric Allen examines the symptoms and causes of this bug, defines ways to prevent this error from occurring, and discusses a tempting hybrid implementation that does not use impostor types but, in the end, turns out to have many of the same weaknesses.
|
|
Articles |
|
01 Jul 2001 |
|
| |
Diagnosing Java Code: The Null Flag bug pattern
Often, our efforts to develop robust programs by substituting null pointers for exceptional conditions actually limits control flow to the ordinary paths of method invocation and return, and buries evidence of where an exceptional condition occured. In this column, Eric Allen shows how this bug pattern, which he calls the Null Flag bug pattern, produces unexpected results that are difficult to debug. As with the other bug patterns that we have discussed, you can minimize occurrences of this pattern by applying certain programming techniques.
|
|
Articles |
|
01 Mar 2001 |
|
| |
Diagnosing Java code: Designing extensible applications, Part 3
Black box extensibility refers to the ways in which a software system may be extended when the source code is neither available for viewing nor for modifying. In this article, Eric Allen expands on the topic of black box extensibility, explains how extensions are made through system configuration or scripting languages, and offers some tips on how to implement black box extensibility.
|
|
Articles |
|
19 Nov 2001 |
|
| |
Diagnosing Java code: Designing extensible applications, Part 2
Glass box extensibility refers to the ways in which a software system may be extended when the source code is available for viewing, but not for modifying -- it lies as the happy medium between black box design (in which extensions are built without viewing the original code) and open box design (extensions are coded directly into the base code). In this article, Eric Allen expands on the topic of glass box extensibility and offers some tips on how to implement it.
|
|
Articles |
|
23 Oct 2001 |
|
| |
Diagnosing Java code: Java generics without the pain, Part 1
This article introduces generic types and the features to support them scheduled for inclusion in Tiger, Java version 1.5, scheduled for release late in 2003. Eric Allen offers code samples that illustrate the ups and downs around generic types by focusing on such Tiger features as limitations on primitive types, constrained generics, and polymorphic methods.
|
|
Articles |
|
20 May 2003 |
|
| |
Diagnosing Java code: Java generics without the pain, Part 4
Java developer and researcher Eric Allen concludes his four-part discussion of generic types in JSR-14 and Tiger by discussing the ramifications of adding support for mixins through generic types.
|
|
Articles |
|
13 May 2003 |
|
| |
Diagnosing Java code: Java generics without the pain, Part 3
Java developer and researcher Eric Allen continues his discussion of generic types in JSR-14 and Tiger with a look at the ramifications of adding support for new operations on naked type parameters in generic types.
|
|
Articles |
|
09 Apr 2003 |
|
| |
Diagnosing Java code: Killer combo -- Mixins, Jam, and unit testing
The safety of single-inheritance programming in the Java language comes at a price: sometimes code must be copied along multiple paths in the inheritance hierarchy. To regain much of the lost expressiveness in single-inheritance Java code, we can integrate mixins as one extension. This month, Eric Allen explains the notion of mixins (classes that are parameterized by their parent class) and how they can aid in unit testing. He also describes a tool for mixin-based programming and discusses potential approaches for adding mixins to your Java code.
|
|
Articles |
|
01 Dec 2002 |
|
| |
Diagnosing Java code: Decoupling package dependencies
In testing programs, how do you meet the tough challenge of simulating outside resources and library connections? Component-based programming and decoupling package dependencies may be the answer. Often touted as a means of facilitating code reuse, component-based software development also makes for more testable code. Eric Allen illustrates this concept of programming with examples from Jiazzi, a powerful, free tool for component-based programming using the Java language.
|
|
Articles |
|
01 Nov 2002 |
|
| |
Diagnosing Java code: Unit tests and automated code analysis working together
Unit testing and static analysis are often seen as unrelated ways to help ensure the correctness of a program. This article examines the relationship between these two methods and covers how the tools that form the working backbone of each method can be used to leverage one another to mutual advantage. Specifically, Eric Allen discusses some of the exciting new applications available that allow you to further leverage your unit tests.
|
|
Articles |
|
01 Oct 2002 |
|
| |
Diagnosing Java code: Using temporal logic with bug patterns
Temporal logic is a formalism used to describe how a program state will change over time. In this article, his second on temporal logic and assertions, Eric Allen discusses how several of the most common bug patterns can be prevented by the use of temporal logic assertions.
|
|
Articles |
|
01 Aug 2002 |
|
| |
Diagnosing Java code: Walking the specification tightrope
Program specifications are a critical but time-consuming part of any software project. In this installment of Diagnosing Java code, author Eric Allen discusses why a well-defined specification for your code is necessary and explores traditional software engineering approaches as well as extreme programming methods. After reading this article, you'll understand how to weigh the costs and benefits of maintaining precise design specs.
|
|
Articles |
|
01 Feb 2002 |
|
| |
Diagnosing Java Code: Depth-first visitors and broken dispatches
Depth-first visitors, a variant on the Visitor pattern, may be used to increase the terseness of your code. In this article, Eric Allen describes the technique, discusses the advantages and the gotchas, cautions the reader about the bug patterns associated with its use, and illustrates depth-first visitors in the context of a specific example.
|
|
Articles |
|
01 Jan 2002 |
|
| |
Diagnosing Java code: Designing extensible applications, Part 4
S-expressions are syntactic representations of lists of elements, delimited by parentheses. In this article, Eric Allen illustrates how S-expressions can be used to provide a useful and lightweight form of black box extensibility and also when they may be detrimental.
|
|
Articles |
|
11 Dec 2001 |
|
| |
Diagnosing Java Code: Improve the performance of your Java code
Many algorithms are expressed most concisely as tail-recursive methods. Compilers can automatically transform such methods into loops and thereby improve program performance, but this transformation is not required by the Java language specification, so not all JVMs will perform it. This means that tail-recursive methods in the Java language can result in unexpectedly large memory usage. In this article, Eric Allen demonstrates that dynamic compilation maintains the language's semantics while static compilation often doesn't. He shows why this matters and offers a bit of code to help you determine whether your just-in-time (JIT) compiler can transform tail recursion on code while preserving semantics.
|
|
Articles |
|
01 May 2001 |
|
| |
Diagnosing Java Code: The Broken Dispatch bug pattern
Method dispatch in an object-oriented language such as the Java language, in which methods can be overloaded and overridden, can cause difficulties of code management in even moderately complex programs. In this week's Diagnosing Java Code, Eric Allen discusses the bug pattern caused by these difficulties, outlining the symptoms when argument mismatches cause the wrong method to be invoked, and offering a few solutions to combat the problem.
|
|
Articles |
|
01 May 2001 |
|
| |
Diagnosing Java Code: The Saboteur Data bug pattern
When a program crashes due to corrupted data, the saboteur can be elusive. Often a program can crash dead in its tracks while manipulating its own internal data, even after working flawlessly for long periods. This article discusses a bug pattern that can be the culprit of this sort of crash, why it exists, and several methods to eliminate it -- before and after it occurs.
|
|
Articles |
|
01 May 2001 |
|
| |
Diagnosing Java Code: The Liar View bug pattern
GUIs are generally designed with a model-view-controller architecture in which the view is decoupled from the model. The separation presents a challenge to automated testing because it's difficult to verify that a state change in the model is reflected appropriately in the view -- it spawns the infamous "Liar View." This installment of Diagnosing Java Code examines the Liar View bug pattern.
|
|
Articles |
|
23 Apr 2001 |
|
| |
Diagnosing Java code: The Double Descent bug pattern
Although usually easier to debug than other, more insidious erroneous behaviors, class-casting error messages are often symptoms of conceptual errors in recursively descending a composite data structure. In this installment of Diagnosing Java Code, Eric Allen discusses where programmers should look to find this pattern of bug, how to recognize the pattern, and what they can do to minimize its occurrence.
|
|
Articles |
|
01 Apr 2001 |
|
| |
Bug patterns: An introduction
This premier article introduces the notion of bug patterns, an extremely useful concept that will increase your ability to detect and remedy bugs in your code.
|
|
Articles |
|
01 Feb 2001 |
|
| |
Testing, fun? Really?
Testing. Yuck! Puh! Aagh! I've always hated testing. Testing, both unit and functional, is something that gets in the way of the "real" work. Everyone knows that their code is perfect, right? In the unlikely event that the code does need to change, the comments are so well written that anyone could figure it out. Wow, am I in need of growth (maybe some counseling as well.
|
|
Articles |
|
01 Mar 2001 |
|
| |
