Course – LS – All
announcement - icon

Get started with Spring Boot and with core Spring, through the Learn Spring course:


1. Overview

When using Spring Data JPA, we often leverage derived and custom queries that return the result in our preferred formats. A typical example is the DTO projection, which offers a great way to select only some specific columns and reduce the overhead of selecting unnecessary data.

However, the DTO projection isn’t always easy and may lead to ConverterNotFoundException when it’s not implemented properly. So, in this short tutorial, we’ll elucidate how to avoid the ConverterNotFoundException exception when working with Spring Data JPA.

2. Understanding the Exception in Practice

Before jumping to the solution, let’s try to understand what the exception and its stack trace mean through a practical example.

To keep things simple, we’ll use the H2 database. Let’s start by adding its dependency to the pom.xml file:


2.1. H2 Configuration

Spring Boot provides intrinsic support for the H2 embeddable database. By design, it configures the application to connect to H2 using the username sa and an empty password.

First, let’s add the database connection credentials to the file:


That’s all we need to set up the H2 configuration with Spring Boot.

2.2. Entity Class

Now, let’s define a JPA entity. For instance, we’ll consider the Employee class:

public class Employee {

    private int id;
    private String firstName;
    private String lastName;
    private double salary;

    // standards getters and setters


In this example, we define an employee by their identifier, first name, last name, and salary.

Typically, we use the @Entity annotation to denote that the Employee class is a JPA entity. Moreover, @Id marks the field that represents the primary key. Furthermore, we use @Column to bind each entity field to its respective table column.

2.3. JPA Repository

Next, we’re going to create a Spring Data JPA repository to handle the logic of storing and retrieving employees:

public interface EmployeeRepository extends JpaRepository<Employee, Integer> {

Here, we’ll assume that we need to display the full name of an employee. So, we’ll rely on DTO projection to select only firstName and lastName.

Since the Employee class holds additional data, let’s create a new class named EmployeeFullName that contains only the first and the last names:

public class EmployeeFullName {

    private String firstName;
    private String lastName;

    // standards getters and setters

    public String fullName() {
        return getFirstName()
          .concat(" ")


Notably, we create a custom method fullName() to display the employee’s full name. Now, let’s add a derived query that returns the full name of an employee to EmployeeRepository:

EmployeeFullName findEmployeeFullNameById(int id);

Lastly, let’s create a test to make sure that everything works as expected:

void givenEmployee_whenGettingFullName_thenThrowException() {
    Employee emp = new Employee();

    assertThatThrownBy(() -> employeeRepository
      .hasMessageContaining("No converter found capable of converting from type" 
        + "[");

As shown above, the test fails with ConverterNotFoundException.

The root cause of the exception is that JpaRepository expects that its derived queries return an instance of the Employee entity class. Since the method returns an EmployeeFullName object, Spring Data JPA fails to find a converter suitable to convert the expected Employee object to the new EmployeeFullName object.

3. Solutions

When using a class to implement the DTO projection, Spring Data JPA uses, by default, the constructor to determine the fields that are supposed to be retrieved. So, the basic solution here is to add a parameterized constructor to the EmployeeFullName class:

public EmployeeFullName(String firstName, String lastName) {
    this.firstName = firstName;
    this.lastName = lastName;

That way, we tell Spring Data JPA to select only firstName and lastName. Now, let’s add another test to test the solution:

void givenEmployee_whenGettingFullNameUsingClass_thenReturnFullName() {
    Employee emp = new Employee();

      .isEqualTo("Azhrioun Abderrahim");

Unsurprisingly, the test passes with success.

Another solution would be to use the interface-based projection. That way, we don’t have to worry about the constructor. So, instead of using a class, we can use an interface that exposes getters for the fields to be read:

public interface IEmployeeFullName {
    String getFirstName();

    String getLastName();

    default String fullName() {
        return getFirstName().concat(" ")

Here, we used a default method to display the full name. Next, let’s create another derived query that returns an instance of type IEmployeeFullName:

IEmployeeFullName findIEmployeeFullNameById(int id);

Finally, let’s add another test to verify this second solution:

void givenEmployee_whenGettingFullNameUsingInterface_thenReturnFullName() {
    Employee emp = new Employee();

      .isEqualTo("Eva Smith");

As expected, the interface-based solution works.

4. Conclusion

In this article, we learned what causes Spring Data JPA to fail with ConverterNotFoundException. Along the way, we saw how to reproduce and fix the exception in practice.

As always, the full source code of the examples is available over on GitHub.

Course – LSD (cat=Persistence)
announcement - icon

Get started with Spring Data JPA through the reference Learn Spring Data JPA


Course – LS – All
announcement - icon

Get started with Spring Boot and with core Spring, through the Learn Spring course:


res – Persistence (eBook) (cat=Persistence)
Notify of
Inline Feedbacks
View all comments