JPA meta model generation fails in 3.7.0.CR1

[nderwin]

Describe the bug

Using the hibernate-jpamodelgen annotation processor with Quarkus 3.7.0.CR1 fails in the compile stage with an odd error about a mapped superclass constructor needing the EntityManager as a parameter. This is a new error with 3.7.0.CR1; changing the attached reproducer to use 3.6.7 compiles without error.

Expected behavior

The project will compile without error and generate a meta model class.

Actual behavior

Compilation error:

jpamodelgen-with-quarkus/target/generated-sources/annotations/org/acme/MyEntity_.java:[10,17] constructor PanacheEntity_ in class io.quarkus.hibernate.orm.panache.PanacheEntity_ cannot be applied to given types;
  required: jakarta.persistence.EntityManager
  found:    no arguments
  reason: actual and formal argument lists differ in length

How to Reproduce?

jpamodelgen-with-quarkus.zip

1. ./mvnw clean compile
2. observe the compile error in the output
3. change the Quarkus version to 3.6.7 (or earlier) in the pom
4. ./mwnv clean compile
5. observe the project compiles without error

Output of uname -a or ver

Linux ---- 6.2.0-33-generic #33~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 10:33:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "17.0.9" 2023-10-17

Quarkus version or git rev

3.7.0.CR1

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

Additional information

No response

[nderwin]

A workaround would be to change the version of the hibernate-jpamodelgen annotation processor to an earlier version, like 6.2.7.Final.

[quarkus-bot]

/cc @DavideD (hibernate-reactive), @gavinking (hibernate-reactive), @gsmet (hibernate-orm), @mswatosh (db2), @yrodiere (hibernate-orm)

[yrodiere]

Thanks for reporting.

I checked that upgrading to maven-compiler-plugin 3.12.1 and Quarkus 3.7.0 (non-CR1) doesn't change anything.

Hey @gavinking , this looks like a bug in jpamodelgen, or at least a side effect: EntityManager gets injected into constructors inconsistently.

For some reason the generated code of PanacheEntity_ looks like this:

@StaticMetamodel(PanacheEntity.class)
public abstract class PanacheEntity_ {
    public static volatile SingularAttribute<PanacheEntity, Long> id;
    @Nonnull
    private final EntityManager entityManager;
    public static volatile MappedSuperclassType<PanacheEntity> class_;
    public static final String ID = "id";

    @Inject
    public PanacheEntity_(@Nonnull EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Nonnull
    public EntityManager getEntityManager() {
        return this.entityManager;
    }
}

And the generated code for MyEntity_ looks like this -- its doesn't have an entityManager parameter in its constructor, and doesn't call the right super constructor:

@StaticMetamodel(MyEntity.class)
@Generated("org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor")
public abstract class MyEntity_ extends io.quarkus.hibernate.orm.panache.PanacheEntity_ {

	
	/**
	 * @see org.acme.MyEntity#field
	 **/
	public static volatile SingularAttribute<MyEntity, String> field;
	
	/**
	 * @see org.acme.MyEntity
	 **/
	public static volatile EntityType<MyEntity> class_;

	public static final String FIELD = "field";

}

FWIW the code of MyEntity is very simple:

@Entity
public class MyEntity extends PanacheEntity {
    public String field;
}

[yrodiere]

I suspect this is a bug in how Hibernate ORM 6.4's jpamodelgen handles inheritance, at least when inheriting classes from external JARs. I'll mark this as triage/upstream, let's wait for @gavinking to confirm (see previous message).

[yrodiere]

I'm working on adding integration tests in Quarkus in the meantime -- and I might have an ugly workaround, too.

We'll still need a fix upstream at some point though.

[yrodiere]

We'll still need a fix upstream at some point though.

FWIW I reported the problem upstream: https://hibernate.atlassian.net/browse/HHH-17683

And created an issue about reverting our workaround: #38451