JicarillaWiki   JavaBeansConsideredEvil UserPreferences
 
HelpContents Search Diffs Info Edit Subscribe XML Print View
 JicarillaWiki   FrontPage   Overview   Articles   GetStarted   Sourceforge Project Page   RecentChanges 

This wiki is in 'slumber' mode, just like its associated sourceforge project. Edits are disabled, the content is potentially stale and is not maintained. That said, it contains some really useful stuff still. Enjoy!

JavaBean Components Considered Evil

This work is licensed under a [WWW]Creative Commons License.

Introduction

If you're reading this, you've likely spent the last few years of your programming life following the ever-present JavaBean paradigm. That's just handy dandy for type-safe configuration, but it wreaks havoc on your application security.

Why is that? The answer is simple: it opens up the possibility of components being in an unsafe state. Which is bad.

Required reading

I assume you are at least passingly familiar with the [WWW]JavaBeans pattern, [WWW]basic component-oriented design and the [WWW]"design by contract" principle. If not, read the [WWW]Design Patterns book and [WWW]some bits on the avalon website.

Unsafe state defined

We say that a component is in an unsafe state when it is not capable of fulfilling the contract of its work interface. Here is a trivial example of a component class that will always result in instances that are in an unsafe state: 

  // Example 1                                                (fragments) 
  public interface MyContract 
  { 
    public void doSomeStuff(); 
  } 
  public class MyComponent implements MyContract 
  { 
    public void doSomeStuff() 
    { 
      throw new UnsupportedOperationException(); 
    } 
  }

More realistically, a component can be in an unsafe state when it has been constructed, but not yet initialized or configured. For example: 

  // Example 2                                                (fragments) 
  public class MyComponent implements MyContract 
  { 
    private MyHelper helper; 
 
    public void setHelper( MyHelper h ) 
    { 
      Assert.assertNotNull( "The helper may not be null!", h ); 
      helper = h; 
    } 
 
    private void doSomeStuff() 
    { 
      helper.helpDoSomeStuff(); 
    } 
  } 
 
  // elsewhere... 
  MyContract comp = new MyComponent();                             // 1 
  try {                                                            // 2 
    comp.doSomeStuff(); // results in NullPointerException         // 3 
  } catch( Exception e ) {}                                        // 4 
  comp.setHelper( new MyHelperImpl() );                            // 5 
  comp.doSomeStuff();                                              // 6

In this example, the component instance 'comp' is in an invalid state on the lines marked 1 through 4. Line 5 corrects this, and the fact that line 6 does not cause an exception proves that the component is, at that point, no longer in an invalid state.

Unsafe states should be avoided!

Clearly, we do not want to use any component instance until it is in a safe state. We should look for a mechanism that ensures that client components will not be able to call any method on any component in an unsafe state.

Use constructors to avoid unsafe state

Fortunately, a powerful and flexible safety mechanism is built right into the java language: the constructor. The suggestion I want to make in this essay is simple: use constructors to avoid unsafe state. That may sound trivial, and it is. We are specifying a contract surrounding the constructor:

But the components in the example above are in blatant violation of that contract. Fortunately, this is trivial to fix: 

  // Example 3                                                (fragments) 
  public class MySafeComponent implements MyContract 
  { 
    private MyHelper helper; 
 
    public MySafeComponent( MyHelper h ) 
    { 
      Assert.assertNotNull( "The helper may not be null!", h ); 
      helper = h; 
    } 
 
    private void doSomeStuff() 
    { 
      helper.helpDoSomeStuff(); 
    } 
  }

In this example, we've only had to change one line of code to make this work. Most realistic components need more than just a helper before they can be considered safe, but the changes to existing beans are quite often just as trivial. Usually the use of the constructor results in less typing!

Note that the assertion statement is important: if it is omitted, the component could be unsafe after returning from the constructor: 

  // Example 4                                               (fragments) 
  MyContract comp = new MySafeComponent( null );                    // 1 
  comp.doSomeStuff(); // results in NullPointerException            // 2

With consistent application of this simple contract applied to all your constructors, you are totally sure that all references to all components in your system are always to components in a safe state. This is a re-assuring fact. And all this from following a simple coding pattern!

JavaBeans are evil

Many JavaBeans do not follow this pattern. Most will use an empty constructor, then use "setters" (as in example 2) to bring a component into a safe state. This is a bad idea, mainly because your average guaranteed-to-be-safe contract is far less simple:

furthermore, these contracts vary on a per-class basis. Some classes might require all setXXX() methods to be called, others may be in a safe state even if some of its setXXX() methods have never been called. A user of such a JavaBean must figure out these contractual specifics, often via a little trial and error.

JavaBeans really are evil

Chances are, that you, will be in strong disagreement with what I just wrote. After all, there's various solutions out there which work just as well and avoid all thes hassles. Right? Well, let us take a look...

Alternative: use a Factory

This idea is pretty simple as well: let something else (not the component author) make sure that all references to all components are always to components in a safe state. You get a reference to a component instance only by asking the factory/container for it, and the factory/container will guarantee that the instance is not in an unsafe state. That usually looks like somewhat this: 

  // Example 5                                               (fragments) 
  public interface Factory 
  { 
    public Object getInstance(); 
  } 
  public class MyComponentFactory implements Factory 
  { 
    public Object getInstance() 
    { 
      MyComponent comp = new MyComponent(); 
      comp.setHelper( new MyHelperImpl() ); 
      return comp; 
    } 
  } 
  public class MyComponent implements MyContract 
  { 
    // package access 
    MyComponent() { /* ... */ } 
 
    /* ... */ 
  } 
 
  // elsewhere... 
  ComponentFactory factory = new MyComponentFactory(); 
  MyContract comp = (MyContract)factory.getInstance();

The contract associated with the factory is this:

Variations on this theme include static factories and factory methods. All of them require another work interface (Factory) and an implementation of that interface (inside the component itself in the case of the factory method), including possibly association of that implementation with the component implementation, and travelling of that association by the client component. (In other words, the client needs to find a reference to the factory and know how to deal with it).

That's considerably more typing. Also note that, in most realistic examples, you need a typecast. While this is usually not a big deal, it just opens a tiny little window for bugs.

I am not saying that the Factory pattern is a bad pattern. But using it merely to avoid having to pass in state through the constructor is not a very good idea, especially not when the use of factories is optional.

Alternative: use a framework

You can take the factory approach further and delegate the instantation and setup of a component to a sort of "generic factory" that also happens to do lots of other things: a container. A sweet example of such a container is the [WWW]Spring framework. Most uses of the spring framework revolve around the component user creating or modifying an xml file. This xml file is read in by the framework at runtime and component instances are created based on the xml file. Here's how you could use Spring with example 2: 

  // Example 5                                               (fragments) 
  <?xml version="1.0"?><!-- config.xml --> 
 
   <!DOCTYPE beans PUBLIC  "-//SPRING//DTD BEAN//EN" 
     "http://www.springframework.org/dtd/spring-beans.dtd"> 
 
   <beans> 
     <bean id="helper" class="MyHelperImpl"/> 
     <bean id="my" class="MyComponent"> 
       <property name="helper"><ref bean="helper"/></property> 
     </bean> 
   </beans><!-- end of config.xml --> 
 
  // somewhere else... 
  InputStream conf = getClass().getResourceAsStream("config.xml"); 
  factory = new XmlBeanFactory( conf ); 
  factory.preInstantiateSingletons(); 
  MyContract comp = (MyContract)factory.getBean( "my", 
    MyContract.class ); 
  comp.doSomeStuff();                                                // 5

Unfortunately, this does not solve anything; it just moves the problem into the xml file. Consider 

  // Example 6                                               (fragment) 
  <beans> 
    <bean id="helper" class="MyHelperImpl"/> 
    <bean id="my" class="MyComponent"> 
      <!-- forgetting the setHelper() here --> 
    </bean> 
  </beans>

it suffers from the exact same problem we saw in example 2: there will be a NullPointerException on line number 5 if you use the fragment from example 6.

Note that this is not a problem with or a bug in the Spring framework. How could the framework possibly know that it is supposed to call the setHelper() method? There is simply no way for the framework to satisfy the desired contract

since it doesn't know about the specific contract surrounding the MyComponent bean

Of course, there's 'workarounds', and many have been proposed. One that seems to be popular is the use of attributes: 

  // Example 7                                               (fragment) 
  /** @@Required */ 
  setHelper( Helper h } { /* ... */ }

where we expect the container to find and interpret the '@@Required' attribute and have it make sure this method is called before agreeing to return an instance. Again, this just moves the problem: now a programmer might forget to add the attribute.

It is just not going to work.

PicoContainer

[WWW]PicoContainer is a container that is in many ways a lot like spring (only its a lot smaller and has a lot less features). One of the cool things about Pico is its ability to call a constructor, with all the proper arguments, for you. Like this: 

  // Example 8                                               (fragments) 
  MutablePicoContainer pico = new DefaultPicoContainer(); 
  pico.registerComponentImplementation( MyHelperImpl.class ); 
  pico.registerComponentImplementation( MySafeComponent.class ); 
 
  MyContract comp = (MyContract)pico.getComponentInstance( 
     MyContract.class );

Conclusion

We started out by defining the concept of "unsafe state", which is a state in which a component does not do its work properly. We briefly outlined what is so bad about allowing components to be in an unsafe state. Then we showed a simple way to avoid that by using the constructor.

Charging on, we visited some attempts to fix the issue in other ways and showed why they're inferior. Finally, I gave a very brief overview of how Picocontainer supports the use of the constructor as I outlined it.

Comments

  // Example 9                                               (fragments) 
  public class MyComponent implements MyContract 
  { 
    public MyComponent( Configuration config, ServiceLocator locator ) { /* ... */ } 
  }
PythonPowered
EditText of this page (last modified 2007-02-18 14:14:22)
FindPage by browsing, title search , text search or an index
Or try one of these actions: AttachFile, LikePages, LocalSiteMap, SpellCheck
Creative Commons License
The contents of this wiki are licensed under a Creative Commons License.