A bean is simply a Plain Old Java Object (POJO) that is managed by a container instead of an application. With this simple definition of a bean, most of your existing Java classes can be utilized as beans with minimal to no changes, such as adding annotations.

public class MyFirstBean {
}

It may not look like much, but the preceding Java class is all that is required for the most basic of CDI beans, which use the @Dependent scope (see Chapter 4, Scopes and Contexts).

To specify a CDI scope other than @Dependent, the bean will need a means for Weld to generate a Proxy (see Chapter 2, Dependency Injection and Lookup) of the bean for injection. For a bean to be able to be proxied by the container, it needs a non-private constructor with no parameters, commonly referred to by Java developers as a default constructor. Our bean is now:

@RequestScoped
public class MyFirstBean {
  public MyFirstBean() {
  }
}

It is also possible for a bean to be proxied by the container if it does not have a constructor with any parameters, but it does require a constructor to be annotated with @Inject, such as the following:

@RequestScoped
public class MySecondBean {
  MyFirstBean firstBean;

  @Inject
  public MySecondBean(MyFirstBean firstBean) {
    this.firstBean = firstBean;
  }
}

In the preceding examples we specified @RequestScoped, but we could also have chosen @ApplicationScoped, @SessionScoped, or @ConversationScoped.

Any object that is bound to a lifecycle context is a bean, which enables CDI to provide support for Java EE Managed Beans and EJB Session Beans. Due to this inherent support in CDI, EJB Session Beans and Managed Beans can inject other beans into them as well as be injected into POJOs that are also beans.

When creating a CDI bean, we need to be concerned only with specifying the type and functionality of any beans that our bean will depend on to complete its work. This frees both the developer and the bean from being concerned with the following:

This loose coupling between a bean and any beans that it depends on not only simplifies the development process, but also supports different use cases through alteration of which concrete implementation is being chosen at runtime, how the bean lifecycle will operate, and which threading model a bean utilizes.

With loose coupling, we could provide an @Alternative (see Chapter 2, Dependency Injection and Lookup) implementation of a credit card provider for use in development and testing environments to prevent spurious credit card payments being triggered, with the implementation that communicates with the credit card provider used only in production.