BeanLint: A JavaBeans troubleshooting tool, Part 2

In last month’s JavaBeans column, “BeanLint: A JavaBeans troubleshooting tool,” we discussed various problems that may cause JavaBeans to fail — either not loading into a development environment or, even worse, failing at runtime. We also introduced a troubleshooting tool called BeanLint, which analyzes class files and reports these potential problems. (To get the most out of what’s being discussed here, you should read last month’s column first; it describes some potential problems JavaBeans might have, and begins to describe how BeanLint works.)

Why BeanLint is important to beans developers

BeanLint is interesting to JavaBeans developers for two reasons. First, it’s obviously preferable to find out about bugs in your software during development or testing, rather than from customer service. The second reason this topic is interesting is that it uses several new and/or advanced features of the Java platform, and, as such, provides good working examples of how to use those features.

Last month’s topics included examples and a discussion of how to use package java.util.zip to read the contents of a jar file, and it covered the creation of a custom ClassLoader class to convert the jar file contents into usable Java classes. This month, we’ll see how BeanLint uses the package java.lang.reflection (a relatively new package introduced in Java 1.1) to analyze class files and look for potential problems.

We’ll have an in-depth look at a potential pitfall in Java’s object serialization, and go over the solution BeanLint offers. Finally, we’ll show how to use the package java.beans.Introspector (part of the standard Java package java.beans) to produce a report of all of the properties, event sets, and other JavaBeans-related attributes of any class file that passes all the tests. But before we start, I’d like to respond to some reader mail.

Several people have said they like the way I’ve been using scrollable text areas to show code examples in a compact way. Others say they don’t like it because the articles, when printed, don’t show all the code. Some have made both observations. One of my mottos is, Why choose when you can have both? So, I’ve continued to put the code in the scrolling text boxes, but any classes or programs I’ve written will also be accompanied by a link to a printable form of the source. Please write and let me know if this solution doesn’t address your concerns.

Checking up on our beans

BeanLint‘s basic approach to finding potential problems in a class file is to load the file as a class, and then perform a series of checks on the class that look for these problems. Last month, we looked at how to get at the bytes that represent a class file, and then how to convert that byte stream into a class. Now, we’ll get into the nitty-gritty of detecting potential problems in our beans. Several of these potential bean flaws have to do with properties of the class methods. The list below covers potential bean problems that can be detected by analyzing a class’s methods, and describes how to detect that problem.

The class itself isn’t declared public

Any class that is supposed to be a bean must be public according to the JavaBeans spec. While some JavaBeans containers will let you get away with not declaring a JavaBean class as public, other containers aren’t so tolerant, and portability is paramount for a JavaBean. The test is simple: verify that the class is public.

The class has no zero-argument constructor.

This can be checked easily enough: verify that the class has a constructor that takes no arguments.

The zero-argument constructor isn’t public.

If the class has a zero-argument constructor, check that it’s defined as public, and complain if it isn’t.

The class is abstract.

If a class is abstract, it can’t be a JavaBean in a useful sense, because it’s not possible (by definition) to create an instance of an abstract class. This isn’t to say a JavaBean can’t inherit from an abstract class, but rather the JavaBean class itself may not be abstract. Fortunately, we can check every potential bean to see whether it is abstract, and produce an error message if it is.

The class doesn’t implement Serializable.

This one’s a trick question. You might say to yourself, “Self, this is easy enough: simply check that the class implements the interface java.io.Serializable.” That’s a worthwhile check to make, but due to certain subtleties in how Java defines serialization, the situation is quite a bit more complex than that. We’ll cover the case of serialization in the second half of this article in the section entitled “Serial killers.”

Notice that in this list, the way to detect the problem is by programmatically determining whether a class has a particular attribute (is it serializable, does it have such-and-such a constructor, and so forth.) We’re in rather strange territory here. Typically, programs use classes to deal with data. But in this case, we’re actually treating the classes themselves as data by making decisions and printing error messages or reports based on information about the class.

A moment for reflection

Analyzing class files is what the package java.lang.reflection is all about. The reflection package, introduced as a core package with Java 1.1, allows Java programmers to ask the JVM questions about classes it has loaded and even classes for which no instances exist. Java programs can, using the classes in the reflection package, determine what methods a class has, what those methods’ parameters are, what fields a methods has, and so forth. This is made possible by a number of API extensions (in 1.1) to java.lang.Class, a class that Java uses to represent a class.

In order for the Java program and the JVM to have a “conversation” about classes, we’ll need classes that represent things like methods, fields, constructors, and so on. That’s where the reflection package comes in.

Among the classes in java.lang.reflection are the following:

• The Field class represents a single, specific field of a class. BeanLint wants to be sure that all nonstatic, nontransient fields of a bean are serializable, so it uses instances of Field in order to check.

• The Method class is a representation of a single method, with a particular name and list of parameters (taken together, the name and parameter list form the signature of the method). A method also has a return type, a list of modifiers (described in the next paragraph), and a list of exceptions that the method might throw. You can even execute the method a Method object represents, by calling its invoke() method. BeanLint doesn’t invoke methods on its beans, but it uses class Method heavily when analyzing serialization (see the section “Serial killers” below.)

• The Modifier class represents a modifier of a method or a field in a class. Modifiers indicate some property of a method, field, or class. For example, they can indicate whether a field is static, transient, or both; whether a class is abstract or is actually an interface; or whether a method is synchronized. Remember that a bean class must be public (as must its zero-argument constructor) so we’ll be using class Modifier to test this bean requirement.

• The Constructor class is similar to class Method, but it represents a constructor instead of a method. As such, it has no method for getting the return value class, since constructors don’t have return values. Since one of the requirements of a JavaBean is that it have a zero-argument constructor, we’ll be using class Constructor to analyze our beans’ constructors.

So, now we have classes that represent the parts of a class (its methods, fields, modifiers, and so on), but how do we get at them? The addition of reflection to Java 1.1 included expanding the information about classes available from java.lang.Class. To get the class object for a class, you can either use the static method java.lang.Class.forName(String classname), passing in the name of the class for which you want a Class object; or, you can ask any Java object instance for its class by simply calling its getClass() method.

java.lang.Class has several methods for returning

information about a class. The return values of many of these methods are instances of classes in the package java.lang.reflect that we’ve just seen. Among the methods of java.lang.Class used by BeanLint are the following:

• Constructor getConstructor(Class[]) returns a constructor with a particular parameter list. The array of Class objects passed into this method corresponds to the types of the parameters, in order, of the specific constructor we’re requesting. For example, in BeanLint, we’re interested in a constructor with no arguments, so we pass in an empty array of Class objects.

• int getModifiers() returns an int that can be decoded by the methods of class Modifier. BeanLint is interested in whether a class or method is public, and uses this method to get that information.

• Class[] getInterfaces() returns an array of Class objects, each of which corresponds to an interface that the class in question implements. There is no Interface class; instead, interfaces are represented by instances of class Class with the “interface bit” set in their modifiers. The Serializable interface must be implemented by all JavaBeans, so BeanLint uses getInterfaces() to determine whether the class being analyzed adheres to this rule.

• Method getDeclaredMethod(String methodName, Class[] parameterTypes) returns a specific method of a class declared in that class; that is, not inherited from a superclass. We’ll use this method in the section on serialization, as well.

BeanLint uses several other methods in these classes. If you run across methods in the BeanLint source that don’t look familiar, check them out in the Java API documentation (see the link in Resources below).

Detecting the madness in your methods

One of the major goals of BeanLint is to detect problems in class methods. Now that we know what reflection is, let’s see how BeanLint uses it to detect the problems described in the first list above. We’re going to dissect the method analyzeBeans(), along with supporting methods. You can find the source for analyzeBeans() in the scrolling text box in Figure 3. If you want to print the BeanLint program, or you just want to see it in one piece, you can find the entire source code at BeanLint.html.

Figure 3. analyzeBeans() loading classes from a

jar file

The method analyzeBeans() is actually fairly simple. First, it sucks all of the beans from the jar file, saving their Class objects in a hashtable, using the class loader we defined last month (lines 394-404). It then iterates through all of the class names in the hashtable, and for each name, it gets the class object for that name and verifies certain facts about each bean. Here’s what it checks:

• The class can be loaded. (Lines 405-420): If findLoadedClass() fails, the class won’t load and therefore it can’t be a bean.

• The class isn’t abstract. (Lines 426-429): We determine whether the class is abstract by using the getModifiers() method of the bean’s Class object and the static method Modifier.isAbstract(). This is the standard way to check modifiers.

• The class is public. (Lines 431-435): We use the class’s modifiers with Modifier.isPublic to determine whether the class we’re analyzing is public, as it must be in order to be a bean.

• The class is Serializable. (Lines 440-443): Since beans must be serializable, we check that this class is. The method isSerializable() (lines 078-086) simply checks to see if the class or any of its superclasses implement java.io.Serializable. Note that this function has changed slightly since last month. See the section entitled “Oops” below for an explanation as to why. As noted before, claiming to implement Serializable and actually doing so are different things. We’ll discuss serializability in depth in the section “Serial killers” below.

• The class has a zero-argument constructor. (Lines 445-455): We use getDeclaredConstructors(), with an empty parameter list, to get the constructor that has no parameters — that is, the zero-argument constructor. We use the getDeclaredConstructors method because we want to ensure that this constructor is defined in this class, not in a superclass.

• The zero-argument constructor isn’t public. (Lines 457-462): We use getModifiers() and the Modifier class yet again, this time on the Constructor object we just retrieved.

• The class has a nonserializable field. (Lines 465-481): If a class has a field that can’t be serialized, then neither can an instance of the class. BeanLint reports any such nonserializable fields as errors. The section “Serial killers” below discusses just what is meant by a nonserializable field.

A class that passes all of these tests is a bean, at least as far as BeanLint is concerned. Once the class’s “beaniness” has been established, BeanLint saves the bean in its hashtable and prints an “introspection report” on the bean, which describes the bean in minute detail. (Remember that the hashtable is the class cache from which the class loader gets its already-loaded classes.)

Let’s continue now and see what introspection really is.

JavaBean introspection

printIntrospectionReport(), shown in Figure 4 (lines 493-521), uses the class java.beans.Introspector to analyze class files as beans. Classes have methods, fields, and modifiers. Beans also have these, since beans are classes, but they also have additional structures such as properties, event sets, and customizers.

java.beans.Introspector uses the reflection package we’ve just learned about to discover information about a class file, and then present that class file to the caller as a JavaBean. The Introspector takes care of finding the BeanInfo object for the bean (if it exists), or of creating a dynamic BeanInfo object (if it doesn’t). It can find a Customizer class for a bean. The Introspector can also determine a bean’s properties and event sets, either by querying the BeanInfo object for the bean, or by using reflection and its knowledge of the JavaBeans naming conventions (called “design patterns” in the JavaBeans spec).

Figure 4. printIntrospectionReport() prints everything you ever wanted to know about a JavaBean

printIntrospectionReport() gets a complete description of the JavaBean from the Introspector and simply prints the results. The PropertyDescriptors are structures used to describe individual properties of the bean, just as a Field object for a class describes a field of the class. Likewise, EventSetDescriptor instances describe individual event sets of the bean.

Let’s finish up this month’s column by going over some subtleties of serialization.

Serial killers

Serialization in Java is easy, but it can be tricky for the uninitiated. (For background on serialization, see my previous JavaBeans columns linked to in the Resources below.)

The first odd point about serialization is that the interface java.io.Serializable has no methods! This makes it extremely easy to implement. All a developer has to do is add implements java.io.Serializable to a class definition, and the interface is implemented. Unfortunately, that doesn’t mean you’ll have no serialization problems.

In fact, a class may claim to implement Serializable, and then fail to perform correctly in actual use. This is because of how Java does its default serialization: it simply tells all of the nonstatic, nontransient fields of the object to serialize themselves. If any one of those fields of the object fail to serialize, the whole object fails. One excellent example of this problem, with which I started last month’s column, was trying to serialize an object that contains an instance of java.awt.Image. Since the Image object isn’t serializable, default serialization for the whole object fails.

Notice that I’ve been saying default serialization. Java serializes objects using the default serialization mechanism unless the object defines custom serialization for that class, by defining the readObject() and writeObject() methods (see the documentation for java.io.Serializable linked in Resources below). If custom serialization for a class is specified, the serialization methods readObject() and writeObject() take care of serializing and deserializing. For example, in our object that contains a java.awt.Image, a developer might choose to define readObject() and writeObject() methods that send or receive the URL of the Image as a string, instead of transmitting the Image itself. Since readObject() and writeObject() exist, the serialization machinery calls them instead of the default, and the problem of a nonserializable field is resolved.

Figure 5. getNonSerializableFields() finds fields that are likely to cause default serialization to fail

What does this have to do with BeanLint? Well, we’re trying to catch as many errors as we can up front, and nonserializable fields definitely will interfere with serialization unless custom serialization is defined. For the purposes of BeanLint, we’re going to say that a field cannot be serialized if all of the following conditions are met (the line numbers refer to the source for getNonSerializableFields() in Figure 5):

• The field is neither transient nor static. (Lines 243-245): The reason for this condition is that default serialization ignores static and transient fields, so they can’t possibly interfere with default serialization.

• The field isn’t primitive. (Lines 263-265): Primitive types like int and double are serializable by definition.

• The class to which the field belongs doesn’t define custom serialization. (Lines 232-246): If a class does define custom serialization, we can assume the developer is aware that nonstatic, nontransient fields need to be attended to manually. (For example, sending a URL instead of an Image.) We’ll assume the developer knows best, and consider nonserializable fields in classes with custom serialization to be taken care of.

  Fields that are arrays or objects have additional constraints:

• If the field is an array, the base type of the array isn’t serializable. (Lines 257-259): Arrays are serializable, as long as their contents are.

• If the field is an object, the object isn’t serializable. (Lines 269-271): Since default serialization tries to serialize all of a class’s fields, any one field that doesn’t serialize causes the entire serialization process to fail.

To make matters just a bit more complicated, default serialization works for the entire object, including fields that are defined in superclasses. So even though your class may not contain a nonserializable object, your class’s superclass may. Therefore, getNonSerializbleFields collects all nonserializable fields, even those in superclasses of the class being analyzed (line 276).

Any field that meets all of these conditions is a nonserializable field, and any class that contains a nonserializable field (based on this definition) almost certainly will not serialize properly. Using BeanLint against your bean before releasing it to testing may help catch these more subtle errors.

Oops!

As noted above, the function isSerializable() has been modified slightly since last month. Alert reader Alexander Rusak of Minsk, Belarus (Vit´j, Alexander!) pointed out a problem with how BeanLint detects whether a class implements Serializable. (See Alexander’s e-mail at bug.html.)

The problem is simply that isSerializable() was checking if the class implemented java.io.Serializable, but it wasn’t checking whether any the class’s superclasses implemented it. So, BeanLint was checking whether a class implemented Serializable directly, where implementing it indirectly (via inheritance) is sufficient. The solution is to check if any superclass implements Serializable.

In the new version of the code, I added one line, and modified another. isSerializable() now checks to see if the Class object it has received is null; if it is, it now returns false (since null obviously can’t implement anything), like this:

079        if (beanClass == null) return false;

The return statement also now calls isSerializable() recursively to check superclasses. If any superclass implements Serializable, it will return true. If the recursion reaches java.lang.Object, the call to getSuperclass() will return null, and the result will be false (because of line 079). The code for the new return statement appears below:

084        return (i < interfaces.length) ||
085          isSerializable(beanClass.getSuperclass());

Thanks (or, rather, dzi´kuju), Alexander, for finding and reporting this problem.

Conclusion

The BeanLint tool can catch a lot of potential errors, but it’s no substitute for proper regression testing.

This month, we’ve taken an in-depth look at BeanLint and the various things that can go wrong in a JavaBean. We’ve leveraged reflection and introspection to detect some of those potential problems, and in the process learned quite a bit about reflection, introspection, and some of the vagaries of default serialization. Please write and let me know if you’ve found BeanLint useful, or what new features you believe it ought to include. You can find my e-mail address in the bio section below.