Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

BeanLint: A JavaBeans troubleshooting tool, Part 1

Use this new tool to avoid JavaBeans loading and runtime problems

By Mark Johnson, JavaWorld.com, 12/01/98

Every couple of months, I receive panicked or bewildered e-mail from a JavaBeans neophyte who is trying to create a JavaBean containing an Image and who can't figure out why the BeanBox won't load the bean. The problem is that java.awt.Image isn't Serializable, therefore neither is anything that contains a java.awt.Image, at least without custom serialization.

I myself have spent countless hours putting println() statements into the BeanBox code then recompiling it, trying to figure out why my beans won't load. Sometimes it's due to some simple, stupid thing -- like forgetting to define the zero-argument constructor, or even the class, as public. Other times, it turns out to be something more obscure.

The case of the missing bean

While the requirements to write a Java class as a JavaBean are simple and straightforward, there are some hidden implications that many bean builder tools don't address. These little gotchas can easily eat up an afternoon, as you hunt through your code, searching for the reason your builder tool can't find your bean. If you're lucky, you'll get a pop-up dialog box with a cryptic error message -- something along the lines of "NoSuchMethodException caught in FoolTool Introspection." If you're unlucky, the JavaBean you've poured so much sweat into will refuse to appear in your builder tool, and you'll spend the afternoon rehearsing the vocabulary your mother tried so hard to cure you of. The BeanBox has long been an egregious offender in this regard, and though it has been improving, it will still drop properties and even whole beans without providing the developer with a single clue as to why.

This month, I'll be leading you out of the "land of the missing bean" by introducing a new tool called, oddly, BeanLint, which analyzes classes within jar files, looking for possible problems that would make the classes unusable as beans. While this tool doesn't cover every possible bean problem, it does identify some of the major common problems that make beans unloadable.

In order to understand how BeanLint works its magic, this month and next we'll delve into some of the lesser-known corners of the standard Java API:

• We'll create a custom class loader, which loads new Java classes from a jar file
  
  
• We'll use the reflection mechanism, which lets Java programs analyze Java classes, to identify what's inside our class files
  
  
• We'll use the Introspector to produce a report of all of the class's beanlike properties for any class in the jar file that passes all tests (and is, therefore, a potential bean)

By the time we're done, you'll have a useful tool for debugging your beans, you'll better understand bean requirements, and you'll learn about some of Java's cool new features at the same time.

Bean basics

For a class file to be a JavaBean, there are two simple requirements:

1. The class must have a public constructor with no arguments (a zero-arg constructor)
   
   
2. The class must implement the empty tag interface java.io.Serializable

That's it. Follow those two simple rules, and your class will be a JavaBean. The simplest JavaBean, then, looks something like this:

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.