Bean Managed Persistence   «Prev  Next»

Lesson 2The entity bean home interface and the create() methods
ObjectiveProgram the entity bean create() methods.

Entity Bean Home interface

Let us first clarify the context and then examine Oracle's current stance based on available information. Entity beans were a core component of the early Enterprise JavaBeans (EJB) specifications, introduced by Sun Microsystems in EJB 1.0 and 1.1, where they served as a way to map individual database rows to persistent objects. However, they were criticized for complexity and inefficiency, leading to their replacement in EJB 3.0 (part of Java EE 5) with the Java Persistence API (JPA), which offered a lighter, more flexible approach to persistence. By the time Java EE transitioned to Jakarta EE under the Eclipse Foundation, entity beans were fully deprecated. In Jakarta EE 9 (released in 2020), support for entity beans was officially removed from the specification, though they had already been optional since EJB 3.2 (part of Java EE 8). This shift reflects a broader industry move away from entity beans toward JPA and other modern persistence frameworks.
Oracle, as the original steward of Java EE before its transition to the Eclipse Foundation in 2017, has continued to play a significant role in enterprise Java technologies, including through its WebLogic Server and cloud offerings. However, Oracle's support for entity beans aligns with the evolution of the EJB specification. In WebLogic Server, which is Oracle's flagship Java EE/Jakarta EE application server, support for entity beans persists for backward compatibility in versions certified for Java EE 8 (e.g., WebLogic 14.1.1.0), where entity beans remained an optional feature per the EJB 3.2 spec. However, there’s no evidence that Oracle actively promotes or enhances entity bean functionality in newer releases or its cloud-native offerings, such as Oracle Cloud Infrastructure (OCI) or Oracle Enterprise Cloud Native Java products. Instead, Oracle emphasizes JPA-based persistence, aligning with modern Jakarta EE standards and customer preferences for lightweight, scalable solutions. Given Jakarta EE 9 and beyond no longer include entity beans, and Oracle’s commitment to supporting Jakarta EE (as seen in their contributions to the Eclipse Foundation), it's reasonable to conclude that entity beans are not supported in Oracle’s latest enterprise technologies targeting current or future Jakarta EE versions, though legacy support may persist in older WebLogic deployments for compatibility with pre-Java EE 8 applications.

The home interface performs a similar function for both 1) entity beans and 2) session beans. There is a single home interface for a particular bean in a container. The home interface allows the client to create and find bean instances. It extends EJBHome in the same way as for session beans. The code below shows the import statements and class signature: 
import javax.ejb.CreateException;
import java.rmi.RemoteException;
import javax.ejb.*;
import java.util.*;

public interface CustomerHome extends EJBHome {

. . .

The methods of the EJBHome were covered under session beans in the first course
in this series and do not change here. They are: 
// EJBHome is provided as part of the EJB API.
public interface EJBHome extends Remote {
  void remove(javax.ejb.Handle handle) throws 
  RemoteException;
  void remove(PrimaryKey key) throws RemoteException;
  javax.ejb.EJBMetaData  get EJBMetaData()throws
  RemoteException;
  HomeHandle getHomeHandle() throws RemoteException;
}


remove(PrimaryKey) for Entity Beans

These methods behave in exactly the same manner as they do with session beans. However, the remove(PrimaryKey) method was not valid for session beans but is valid for entity beans. Entity names can be confusing. An entity object is the underlying persistent data object. An instance, or entity bean instance, is an EJB that represents the in-memory representation of the underlying entity object.
  • Create() methods
    The create() methods in the Home interface are invoked by the client when it wishes to create a new persistent entity object. Its arguments represent, at a minimum, enough information to create a unique persistent entity object. There can be zero or more create() methods. If there are none, then the client has no way of creating a bean and must use existing entity objects. This is a valid situation, as not all applications need to create new entity objects. The create() methods return an EJBObject stub in the same way as session bean create() methods. The create() methods in the home interface for the Customer bean are as follows: 
    public interface CustomerHome extends EJBHome {

public Customer create(String custnum) throws       
CreateException, RemoteException;

public Customer create(String custnum, String name) 
throws CreateException, RemoteException;

In the example, the first create() method will create an empty row for a specific customer. The second create() method creates a complete row. There may be many arguments in some create() methods if the persistent entity is large. The next lesson explains how the create() methods in the home interface map to the ejbCreate() methods in the bean.

SEMrush Software