IntelliJ IDEA Java

Reverse Engineering with Hibernate 7.4 and IntelliJ IDEA

Reverse Engineering in the context of database-driven application development means generating Java persistence artifacts such as entity classes and mapping files from an existing database schema.

This is useful when the database already exists, especially in legacy systems or large projects where creating entity classes manually can be slow and error-prone.

Until now, these features were provided by the separate Hibernate Tools project. Starting with Hibernate 7.4, the core Hibernate Tools modules are part of the Hibernate repository. Maven and Gradle (and even Ant) users can now access reverse engineering through the Hibernate build plugins. This is especially useful for database-first projects, where the schema already exists and the application needs an initial set of persistence artifacts.

IntelliJ IDEA also provides Reverse Engineering features that can help developers generate JPA entities from an existing database, generate Flyway or Liquibase migrations from JPA/JDBC entities, and much more.

In this article, let us explore both Hibernate 7.4 and IntelliJ IDEA Reverse Engineering capabilities and understand which tool to use in which scenario.

You can check out the sample code for this article in this GitHub repository.

Hibernate 7.4 Reverse Engineering

Hibernate 7.4 can inspect an existing database and generate artifacts such as:

• JPA entity classes
• Hibernate mapping files
• DAO-style helper classes
• Database schema SQL scripts

In the sample project, the reverse engineering workflow is configured using the Maven plugin with reverse engineering customization specified in hibernate-reverse-engineering.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering SYSTEM
        "https://hibernate.org/dtd/hibernate-reverse-engineering-3.0.dtd">
<hibernate-reverse-engineering>
    <type-mapping>
        <sql-type jdbc-type="NUMERIC" hibernate-type="big_decimal"/>
        <sql-type jdbc-type="OTHER" hibernate-type="pg-uuid"/>
    </type-mapping>

    <table-filter match-name=".*" package="com.jetbrains.entities"/>
    <table-filter match-name="flyway.*" exclude="true"/>

    <table name="products" class="Product">
        <primary-key property="id">
            <generator class="sequence">
                <param name="sequence_name">product_id_seq</param>
            </generator>
        </primary-key>
        <!-- other config -->
    </table>

    <!-- other tables config -->
</hibernate-reverse-engineering>

This configuration lets us customize type mappings, package names, table filters, class names, and primary key generation. 

Configure the hibernate-maven-plugin in pom.xml as follows:

<properties>
   <!-- update the version to the newer version of Hibernate -->
   <hibernate.version>7.4.0.CR1</hibernate.version> 
</properties>

<plugin>
    <groupId>org.hibernate.orm</groupId>
    <artifactId>hibernate-maven-plugin</artifactId>
    <version>${hibernate.version}</version>
    <configuration>
        <revengFile>hibernate-reverse-engineering.xml</revengFile>
    </configuration>
    <executions>
        <execution>
            <id>generate-entities</id>
            <phase>generate-sources</phase>
            <goals>
                <goal>hbm2ddl</goal>
                <goal>hbm2java</goal>
                <goal>hbm2dao</goal>
            </goals>
        </execution>
    </executions>
</plugin>

The hbm2java goal generates JPA entity classes from database metadata, while hbm2ddl can generate database schema SQL. The hbm2dao goal can generate DAO-style helper classes with methods to perform CRUD operations on entities.

To generate the artifacts, run:

$ ./mvnw generate-sources

This Maven goal generates JPA entities and DAO classes in target/generated-sources, and schema.ddl file in target/generated-resources directories.

Regeneration and Version-Controlled Workflows

Generated code is rarely the final version of an application model. After the first generation, developers often add validation annotations, helper methods, domain logic, fetch strategies, and other project-specific changes.

If these files are regenerated later, manual changes can be overwritten. This is why a regeneration workflow may not be ideal when developers edit generated entities directly.

However, regeneration is not always a drawback. Some teams prefer to keep the reverse engineering configuration in source control and make generation part of the build. In this setup, the output is reproducible, works in CI/CD, and does not depend on a specific IDE.

For example, a CI check can regenerate the artifacts and fail if the generated files are different from the committed version.

IntelliJ IDEA Reverse Engineering

IntelliJ IDEA provides a more interactive and flexible reverse engineering workflow. Instead of creating and maintaining a reverse engineering XML file, we can connect to a database from the IDE, select the tables, and generate JPA entities directly.

More importantly, IntelliJ IDEA supports progressive synchronization between the database schema and the code. When the database changes, the IDE can help sync those changes into existing entity classes without forcing a full regeneration. This helps preserve manual modifications that were made after the initial generation.

More Feature-Rich and Flexible

IntelliJ IDEA’s reverse engineering provide additional features apart from generating JPA entities from tables. The IDE supports related workflows such as:

• Generating JPA entities from an existing database schema
• Synchronizing database changes into existing entity classes
• Preserving manual changes during incremental updates
• Generating Flyway migrations from JPA entities
• Generating Liquibase migrations from JPA entities
• Supports Spring Data JDBC entities in addition to JPA

To learn more about these features, explore the following articles:

• How to Use Flyway for Database Migrations in Spring Boot Applications
• Spring Data JDBC Made Easy with IntelliJ IDEA

This makes IntelliJ IDEA a better fit for day-to-day development, especially when the schema and code evolve together. It provides a guided workflow, visual database integration, and incremental updates without requiring a build-time generation configuration for every change.

Choosing the Right Workflow

Hibernate 7.4 reverse engineering is a strong option when we want a repeatable, build-driven process. It works well for generating the initial version of entities and schema SQL from an existing database, especially in automated workflows.

IntelliJ IDEA is more suitable when we want an iterative workflow. It helps developers  progressively synchronize code and database changes without losing manual entity customizations. It also supports additional workflows around migrations and Spring Data JDBC, making it more feature-rich and flexible for application development.

Summary

Both approaches solve the same core problem of generating Java persistence artifacts from an existing database schema, but they are designed for different situations.

Use Hibernate 7.4 Reverse Engineering when:

• You want the generation to be part of the build process to generate entities, DAOs, .hbm files based on the current database schema.
• You need this to work in any IDE, or from the command line, or in a CI/CD pipeline, since it runs through Gradle or Maven.
• You are comfortable regenerating entities, DAOs, and .hbm files from a version-controlled reveng.xml file rather than editing generated code by hand.

Use IntelliJ IDEA Reverse Engineering when:

• You want an interactive and visual way to generate entities without writing any XML configuration.
• Your database schema changes over time, and you need to keep the entity classes in sync without losing the custom logic you have already added.
• You are working with Spring Data JDBC in addition to JPA, or you need to generate Flyway or Liquibase migration scripts.
• You have an IntelliJ IDEA Ultimate subscription and don’t need reverse engineering to run outside the IDE (for example, in a CI/CD pipeline)

IntelliJ IDEA is generally a strong choice for day-to-day development because it lets you evolve the database and the Java model together, as long as you have an Ultimate subscription and don’t need the step to run outside the IDE. It understands what already exists in your code and can merge schema changes into it, rather than replacing everything from scratch. 

If your team needs this to run in any IDE or as part of a CI/CD pipeline, or if you prefer a version-controlled, reproducible generation step, Hibernate 7.4’s build-tool-based reverse engineering is the better fit.

If you are starting a brand-new project from an existing database, either approach can give you a solid starting point. From there, the right choice mostly comes down to your team’s workflow and tooling constraints.