What causes "Could not instantiate entity" in hibernate/hibernate-orm?

Unwrap the cause chain — the real failure (NPE in ctor, IllegalArgumentException from a setter, IllegalAccessException) names the exact field/method to fix.

hibernate/hibernate-orm · error · InstantiationException

Could not instantiate entity

Error message

Could not instantiate entity

What it means

This is the catch-all of EmbeddableInstantiatorPojoStandard.instantiate: after the abstract-class and constructor-null guards pass, it calls constructor.newInstance() and then embeddableMappingAccess.get().setValues(instance, values) to push the loaded state onto the fresh instance. Any Exception thrown there — constructor failure, setter/field write problems (wrong type, access denied, setter threw) — is wrapped as InstantiationException("Could not instantiate entity") with the original cause preserved.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/metamodel/internal/EmbeddableInstantiatorPojoStandard.java:76

		try {
			final var values = valuesAccess == null ? null : valuesAccess.getValues();
			final Object instance = constructor.newInstance();
			if ( values != null ) {
				// At this point, createEmptyCompositesEnabled is always true.
				// We can only set the property values on the compositeInstance though if there is at least one non null value.
				// If the values are all null, we would normally not create a composite instance at all because no values exist.
				// Setting all properties to null could cause IllegalArgumentExceptions though when the component has primitive properties.
				// To avoid this exception and align with what Hibernate 5 did, we skip setting properties if all values are null.
				// A possible alternative could be to initialize the resolved values for primitive fields to their default value,
				// but that might cause unexpected outcomes for Hibernate 5 users that use createEmptyCompositesEnabled when updating.
				// You can see the need for this by running EmptyCompositeEquivalentToNullTest
				embeddableMappingAccess.get().setValues( instance, values );
			}

			return instance;
		}
		catch ( Exception e ) {
			throw new InstantiationException( "Could not instantiate entity", getMappedPojoClass(), e );
		}
	}
}

View on GitHub (pinned to fad1729dce)

Solutions

Unwrap the cause chain — the real failure (NPE in ctor, IllegalArgumentException from a setter, IllegalAccessException) names the exact field/method to fix.
Make property setters/fields writable by Hibernate: avoid throwing validation in setters used for hydration; move validation to @PrePersist/@PreUpdate.
After changing property types, migrate or clean existing data so setValues receives convertible values.
Under JPMS, ensure the embeddable's package is open (opens com.example.model to hibernate.core or all-unnamed) so reflective writes succeed.

Example fix

// before
@Embeddable
public class Email {
    private String value;
    public void setValue(String value) {
        if (!value.contains("@")) throw new IllegalArgumentException(); // breaks hydration of legacy rows
        this.value = value;
    }
}

// after
@Embeddable
public class Email {
    private String value;
    public void setValue(String value) {
    	this.value = value; // validate in @PrePersist/@PreUpdate instead
    }
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
    Entity e = session.find(Entity.class, id);
} catch (InstantiationException e) {
    if ("Could not instantiate entity".equals(e.getMessage())) {
        Throwable cause = e.getCause(); // real failure: ctor threw, setter rejected value, access denied
        log.error("Embeddable hydration failed for {}", e.getClassName(), cause);
    }
    throw e;
}

Prevention

Do not throw from setters used during hydration — validate in entity lifecycle callbacks.
After changing embeddable property types, migrate stored data before deploying.
Open the embeddable package under JPMS so reflective field writes succeed.

When it happens

Trigger: Hydrating an @Embedded/@ElementCollection attribute where the no-arg constructor throws, or where writing a property value fails: type mismatch between the mapped property and the loaded value (e.g. after changing a field type without schema migration), setters with validation that rejects loaded values, or JPMS/SecurityManager blocking reflective writes.

Common situations: Setter methods that validate and throw on legacy/bad data already in the table; entity type changed (String -> enum) while old rows hold unmappable values; private final fields without accessible setters after refactors; constructors with side effects (logging, service calls) that throw in the persistence context; modules not open to hibernate.core.

Related errors

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/bdbe02b5adeae525. Report an issue: GitHub.