This comes from discussions on https://hibernate.atlassian.net/browse/HHH-10690, https://github.com/hibernate/hibernate-orm/pull/1723 and Hip Chat...

To properly account for the Java parameterized-type bindings for the attribute type, we should really know what Class in the hierarchy that we want the attribute type for. E.g.

@MappedSuperclass
public class AbstractEntity<ID extends Serializable, D> {
  @Id
  private ID id;
  private D data;
}

@MappedSuperclass
public class BaseEntity extends AbstractEntity<Long, String> {
  private Integer value;
}

@Entity
public class SomeEntity extends BaseEntity {
}

When the JPA user asks the id field or the data field Attribute's Java type, the answer really depends which specific class in the Attribute owner's hierarchy we are talking about.

To account for this one option is to vary the Attribute instance we get back from each specific class. But that causes problems with equality (==).

The better way, IMO, is adding the ability to get the Java type of the Attribute relative to a specific owner hierarchy class. E.g. (using the model above):

MappedSuperclassType<AbstractEntity> owner = ...;
Attribute<AbstractEntity,Object> idAttribute = owner.getId( Object.class );

assert Serializable.class.equals( idAttribute.getJavaType() );
assert Serializable.class.equals( idAttribute.getJavaType( AbstractEntity.class ) );
assert Long.class.equals( idAttribute.getJavaType( BaseEntity.class ) );
assert Long.class.equals( idAttribute.getJavaType( SomeEntity.class ) );