Booster #1: Spring Data

Top 3 JPA productivity boosters for Java EE developers – Spring Data

Matti Tahvonen
Booster image via Shutterstock

There are a lot of ways to be inefficient writing Java EE applications. But there’s three ways to enhance your JPA productivity, each of which Matti Tahvonen lays out in this three-part series, starting with Spring Data.

Using JPA, container managed persistence context and automatic JTA transaction management in modern Java EE environments is really easy these days. Just define your stateless EJB, inject the EntityManager using the @PersistenceContext annotation and you are ready for safe, easy and scalable database access.

But if you write a lot of Java EE applications, you will soon notice that you’re spending a considerable amount of time with the JPA APIs. In case you are using DAOs, you are writing almost identical CRUD methods for each and every entity type. And you’ll spend a lot of time debugging your JPQL/SQL queries or creating the same queries with somewhat cumbersome Criteria API.

A lot of this inconvenience can be avoided by throwing in some handy helper libraries. In this series I’ll introduce you to three of them: Spring Data, DeltaSpike Data and QueryDSL. Although none of those is a standard piece of the Java EE stack, they use standard APIs behind the scenes and your application can maintain its portability, while you can gain some productivity. To support the article I also wrote an example application with a Vaadin UI that can use any of the three different phone book facades implemented with the libraries.

Spring Data

Mentioning Spring in a Java EE article will probably create mixed feelings among some of you. But hey, why not? Spring Data is a great stable library, loved by many Spring users, makes you really productive when starting with your DAOs and it is easily available to Java EE folks using its built in CDI integration. 

At the heart of Spring Data are its repository interfaces that you create for your entity objects. Spring Data will then automatically implement the most common DAO methods. For a really simple CRUD you only need the default methods defined in the super interface.

You can add custom methods by defining them to the interface only. You can define the query explicitly with an annotation, but the really cool part is that Spring Data can in many cases implement your query based on a method naming convention. E.g. the following interface will provide all the typical CRUD methods (inherited from JpaRepository) and a query returning all contacts in a specific Company. No JPQL or Criteria API fiddling is needed.

    public interface ContactRepository extends JpaRepository<Contact, Long> {
        public List<Contact> findByCompany(Company company);

To make this awesomeness work in a Java EE environment, you need to configure your CDI container to provide a way to access your container managed EntityManager. This can be accomplished with the following simple configuration class:

    public class CdiConfig {

        @PersistenceContext(unitName = "customerdb")
        public EntityManager entityManager;


In Spring apps I have sometimes just brutally injected Spring Data repositories directly to my UI code. Not the most architecturally beautiful approach, but really handy in simple CRUD examples without any real business logic. When you use Spring Data in a Java EE environment, you should always create a DAO or a facade in front of your “repository”.

In addition to being a better habit, the stateless EJB is also a dead simple method to tackle transaction marshaling, something that cannot be tackled by plain CDI and Spring Data. The stateless EJB DAO, without writing any characters of query language or tricky JPA Criteria API, could look like this:

    public class ContactFacade {

        ContactRepository repository;

        public Contact save(Contact entity) {

        public void delete(Contact entity) {

        public List<Contact> findAll() {
            return repository.findAll();

A minor drawback in using Spring Data in Java EE environment is that it depends on a largish set of other Spring libraries, that you probably are not using if you base your application on a “standard stack”. I wouldn’t worry too much about that. It adds only a minor overhead to the deployment time and some megabytes increase to your war file size, irrelevant when you compare that to the improved developer productivity. 

In case you are already familiar with Spring Data JPA and love it, there are no real reasons to avoid it in a Java EE application. It is a rock solid industry proven basis for your data access layer, intuitive and elegant, and available for your Java EE apps as well.

Check out and play with the example project to see how you can use Spring Data in your Java EE application. It also contains different versions of the facade implemented with DeltaSpike Data and QueryDSL that I‘ll introduce in the next episodes of the article series.

In the next part of this article series, I introduce another similar library, DeltaSpike Data. It is heavily inspired by Spring Data, but it is targeted to CDI containers instead of Spring based environment.

Continue reading about JPA booster #2: DeltaSpike Data.

Matti Tahvonen
Matti Tahvonen has a long history in Vaadin R&D: developing the core framework from the dark ages of pure JS client side to the GWT era and creating number of official and unofficial Vaadin add-ons. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies.

Inline Feedbacks
View all comments
2 years ago

Honestly, the more I work with SpringData the more I can only discourage using it. I’ve worked with a custom in-house framework based on JPA annotations before. While that required a tiny bit more boiler plate code, it was easy to hide that and writing that code took way way less time than dealing with problems that arise from Spring Data.

Reply to  Thaniell
2 years ago

Could you please elaborate more? Maybe write an article? From my experience not using spring-data is huge pain in the a**, we have multitude of repositories and it’s crazy to maintain such code when you could just have clean spring-data repositories?