Lazy loading vs. pre-loading beans with Spring Framework

Spring framework can instantiate and bind (called loading) related Java objects (called beans) according to a given configuration. An XML file can easily be used to define these bindings. Spring framework supports two different types of loading methods; lazy loading and pre-loading respectively managed by BeanFactory and ApplicationContext containers.

Lazy Loading

A bean is loaded only when an instance of that Java class is requested by any other method or a class. org.springframework.beans.factory.BeanFactory (and subclasses) container loads beans lazily. Following code snippet demonstrate lazy loading, concentrate on how "beans.xml" spring configuration file is loaded by BeanFactory container class.

BeanFactory factory = 
    new XmlBeanFactory(
     new InputStreamResource(
      new FileInputStream("beans.xml")));// 1
Employee emp = (Employee) factory.getBean("employeeBean");// 2

Even though "beans.xml" configuration file is loaded with BeanFactory container in line number 1, none of the beans will be instantiated. Instantiation takes place only at line number 2, where bean called "employeeBean" is requested from container. Since the class is instantiated at getBean() method call, time spend to return this method will vary depending on the instantiated object.

Pre-loading

All beans are instantiated as soon as the spring configuration is loaded by a container. org.springframework.context.ApplicationContext container follows pre-loading methodology.

ApplicationContext context =
    new ClassPathXmlApplicationContext("beans.xml"); 1 
Employee emp = (Employee) context.getBean("employeeBean"); // 2

As all singleton beans are instantiated by container at line number 1, this line will take some considerable time to complete. However line number 2 will return the bean instance immediately since instances are already available inside the container.

Point to note

Decision to choose one from these two methods would depend solely on application specific requirements. Some applications need to load as soon as possible while many others would probably willing to spend more time at startup but serve client requests faster. However some of the beans defined in a configuration may only be used rarely, so instantiating such classes at start up would not be a wise decision. Similarly, some Java instances would be highly resource consuming; leading not to instantiate at start up.

Related articles

• Use <object> instead of <bean> in Spring Configuration XML

Use "object" instead of "bean" in Spring Configuration XML

Spring configuration xml is used for defining the wiring between different object. It has the following format.

<beans>
    <bean id=".." class="...">
        ...
    </bean>
    ...
<beans>

Classes specified in the configuration file will be instantiated by Spring container. And those objects will be bound with each other accordingly. Any java class specified under attribute named "class" will be instantiated. There is no much limitations on the classes that can be used for this here. It does not need to be a JavaBean. It can be any POJO (plan old java object). The only requirement is that this class must be possible to instantiate.

So why does this tags are named <beans> and <bean>? This seems to be misleading.

In Spring one way of binding objects is using the beaness of java classes. But that is not that only way to bind them together, constructor can be used to bind objects. So if configuration file used tags as follows, it would be more meaningful.

<objects>
    <object id=".." class="...">
        ...
    </object>
    ...
<objects>

Seems it is used only to express that beaness can also be used in initialization. Would you agree? May be we are not seeing the exact reason. This is completely open for discussion.

Related Articles

• Firefox: Dramatic change in release version patterns
• Are You Leaving Office On Time or Late Continuously?