Understanding the Benefits of Develop Jakarta EE Application Based on Spec

Jakarta EE is an umbrella project based on Java EE 8, that contain a set of specs. These specs are the same specs of Java EE 8, but migrated from Oracle to Eclipse Foundation. With this, Jakarta EE Platform provide the same features then Java EE 8 and permit us develop applications without carer about vendors.

The Java ecosystem have been provided more and more tools to develop decoupled applications. The word decoupled application can appear vage and to turn the understanding better, we’ll explain a definition of decoupled application to us.

Decoupled Applications

The level of decouple between elements (Components, Applications, Services) is directly related with the level of abstraction of its details. Thus, if two elements are decoupled, that means that both element don’t need know the details of other element. For instance, if the service “register” is decoupled from service “payment”, then the service “register” don’t know the details of implementation of service “payment”, and the service”payment” don’t know the details of implementation of service “register” . Both will only know that when a service is called the service will generate a specific action, but will not know how this action will be done. It permit us change a service without affect the other service.With this, the architecture turn more plugable.

In an application development, we can achieve several kind of decouple, such as decouple of configurations, decouple of codes, decouple of infrastructure, and to Jakarta EE we can promote a decouple of vendors. With this, when I develop an application with a decouple from vendors, we will be free to use any vendors without change the code.

Jakarta EE Application Based on Spec

When I’ll write an application using Jakarta EE, I can use the specs without using specifics features of vendors or using features of vendors. Then, when I use features of some vendors, my application turn coupled with the respectively vendor and this vendor become a dependency of the application. With this, if you want to change one vendor to another vendor, you will need update the code.

Jakarta EE application based on spec is an application that is wrote using only the specs and without using features of some specific vendor. With this, a Jakarta EE application based on spec don’t know about details of which vendor will be used and don’t have a couple or dependency with any vendors. This concept is very similar with concepts of interface and class of object-oriented programming, where, the specs are like interfaces and the implementations of a vendor are like classes.

The benefit of write a Jakarta EE application based on spec is the decoupled between application and vendor. With this, you can run your application using any vendor. For instance, if you create a Jakarta EE Application that uses the JPA spec you can run this application on Widfly that have the Hibernate as a JPA implementation, on GlassFish that have the EclipseLink as a JPA implementation, or another application server that contain another vendor to JPA implementation. Thus, your application becomes a potable application.

Writing Code Using Jakarta EE Spec

To show an example of write a code based on spec we’ll figure out a scenario using JPA spec. We gonna mapping a table called person of a relational database and writing a DAO to read and write datas in this table. Below we have the figure showing model of table.

First of all we’ll create the persistence.xml to configure the unit persistence. Below we have the persistence.xml.

<persistence>
    <persistence-unit name="javaee8">

        <jta-data-source>jdbc/MyDataSource</jta-data-source>
        <properties>
            <property name="javax.persistence.schema-generation.database.action" value="create" />
        </properties>

    </persistence-unit>
</persistence>

Note that we configure the property called javax.persistence.schema-generation.database.action that is a property of JPA to create the schema on the database automatically. This property will work with any vendor.

Creating Entity

Now, we will create the entity called Person, that is the class to mapping the table person contained on the database.

@Entity(name = "person")
public class Person implements Serializable{

    @Id
    @GeneratedValue
    @Column
    private Long id;

    @Column
    @NotBlank
    private String firstName;

    @Column
    @NotBlank
    private String lastName;

    //Getters and Setters

    //equals and hashCode

}

Note that on the code above, we used only feature of JPA spec and don’t used feature of some specific vendor.

Creating DAO

Now, we’ll create the PersonDao class that is a DAO responsible to read and write datas on table. The PersonDao is a stateless Session Bean of EJB.

<
@Stateless
public class PersonDao {

    @PersistenceContext
    protected EntityManager em;

    public Optional<Person> findById(Long id){

        return Optional.ofNullable(em.find(Person.class, id));
    }

    public List<Person> findAll(){

        return em.createQuery("select p from "+Person.class.getName()+" p ", Person.class)
                .getResultList();

    }

    public Person save(Person person){
        return em.merge(person);
    }
}

Note that on the code above we uses only feature of JPA spec.

Conclusion

To define if we’ll develop an application based on spec or using features of vendors we need understanding the necessities of the application at moment of development. If you should writing the application independent of vendors you shall develop the application based on spec. However, if you will have gain using features of specific vendor you can develop the application using the vendor. My advice for you is: Have preference to develop Jakarta EE application based on spec. Because your application becomes portable and it’s closer to cloud native application.

If you want see all codes of our example access: https://github.com/rhuan080/jakartaee-example-jpa