Alexander Pinske thanks for the report. This is both a bug and a missing feature. For reference, let me explain both and then let's focus on the missing feature.

The bug is that we have a slightly different code generation for the case where there is no lazy loading involved, and that is failing for attributes that come from a @MappedSuperclass. It's an easy fix, that comes naturally with the changes that are required below.

The missing feature is that the current design does not support private fields on the @MappedSuperclass. The reason for that being that since they are not visible in the entity they can not be used on the bye-code we add to it.

Although it may sound impossible, there is actually a way to implement the feature. We already add 'template' methods on the super class and those expose the private fields. In the entities we can use them to gain access to those private fields. The code generation becomes more complex, because where before this.attribute was used now a call has to be made to super.$$_hibernate_read_attribute(). Same, if not a little harder, to set a value.

It's assumed that if an entity class is byte-code enhanced, the @MappedSuperclass that declares the field will be byte-code enhanced as well.

One last note to mention that managing bi-directional associations is not supported, at least when they are private. The code generation is already complex enough using this.attribute. That should not be an issue because on JPA spec, section 2.11.2, it's stated that any relationship on a @MappedSuperclass must be unidirectional.