MappedSuperClass annotation

[Pidi]

If an abstract class inherits from an abstract superclass annotated with
@MappedSuperclass, it inherits the annotation too or if I want both
annotated I have to replicate the annotation?

Ex:
@MappedSuperclass
public abstract Class1 {
...
}

@MappedSuperclass <-- I have to declare it or it's implicit?
public abstract Class2 extends Class1{
...
}

[Lew]

You have to declare it. Annotations do not inherit.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[Daniel Pitts]

On 1/27/12 10:50 AM, Lew wrote:
> Pidi wrote:
>> If an abstract class inherits from an abstract superclass annotated with
>> @MappedSuperclass, it inherits the annotation too or if I want both
>> annotated
>> I have to replicate the annotation?
>>
>> Ex:
>> @MappedSuperclass
>> public abstract Class1 {
>> ...
>> }
>>
>> @MappedSuperclass <-- I have to declare it or it's implicit?
>> public abstract Class2 extends Class1{
>> ...
>> }
>
> You have to declare it. Annotations do not inherit.

True, and that annotation specifically needs to be declared everywhere
you want the effect.

In general though, it is up to the framework which utilizes the
annotations to decide if they want to climb up the inheritance or not.

[Lew]

Good point, but I couldn't come up with an example that does, and certainly
none for JPA.

This is at least hinted if not evident from the documentation, for example:
<http://docs.oracle.com/javaee/6/tutorial/doc/bnbqn.html>
in which the very introduction of entities shows the need to repeat the
'@Entity' annotations at each level of inheritance.

That said, the need for multiple levels of inherited '@MappedSuperclass'
annotated types should be vanishingly rare. There's a very, very good chance
that the OP should *STOP* what they're doing and reconsider, then get rid of
the idea. I cannot even think of a scenario where it would help. It goes
firmly against the intended purpose of that annotation.

[Arved Sandstrom]

Leaving aside JPA for the moment, you can in fact inherit annotations on
_classes_ where the annotation has the @Inherited meta-annotation. This
has been so since Java 1.5.

It's not used much: I stand to be corrected but I think no annotations
in the "java" package and only 3 annotations in "javax", in base JDK
1.6, use the @Inherited meta-annotation. One such is
javax.xml.ws.ServiceMode, so if a JAX-WS 2.0 provider class happens to
use the @ServiceMode annotation, any class that extends that provider
class will also have it.

JSR-250 has very little to say about this meta-annotation and I believe
mentions it only once, in the discussion of @Resource. The general
thrust of JSR 250 (see Section 2.1 "General Guidelines for Inheritance
of Annotations") is to acknowledge, as you guys have pointed out, that
individual specifications have decided how to treat annotation
inheritance. Although it's worth pointing out that JSR 250 does provide
recommendations in this regard.

I'm not so sure but that the JSR 250 authors don't implicitly deprecate
the use of @Inherited, although I don't see that they ever flat out say so.

In any case @Inherited is somewhat dangerous. One hopes that it is
*always* accompanied by the @Documented meta-annotation, so that at
least on the originally annotated class users can see that it is there,
and if things start to misbehave they can follow the Javadoc link and
see that that annotation is in fact inherited. I've seen posts where
people did run into problems because they had no idea that an annotation
was @Inherited; Javadoc (AFAIK) does not follow annotation inheritance
and display the inherited annotation information on children. One might
have to subclass the standard Javadoc doclet to get that, I dunno.

It's a bit worse than that because @Inherited affects the complete depth
of inheritance. It will apply to children of children of children...

In any case, I agree with both of you when it comes to @MappedSuperclass:

1) Since it does not have the @Inherited meta-annotation you do have to
declare it on every class that needs it (according to Java language
annotation rules);

2) Point #1 is semi-irrelevant because each framework, JSR 250 be
damned, can do whatever it wants to;

3) Even if @MappedSuperclass did have the @Inherited meta-annotation,
*or* JPA implementations analyzed it in the same effective way, you (the
OP) still wouldn't want to do what you want apparently to do. JPA
provides a *lot* of mechanisms foe helping people out when there is a
serious mismatch between their RDBMS table setup and their object
hierarchy, but it also works best when you've got a 1:1 mapping between
tables and simple JPA entities. No problem with a single depth use of
@MappedSuperclass [1], but I wouldn't take it any further than that.

AHS

1. Fairly common to use @MappedSuperclass simply because a lot of
implementations have generic fields that relate to every entity/table
for auditing, for example. Although DBs audit too this data is not
always as accessible to an application.
--
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

[Daniel Pitts]

I have needed multiple levels of inheritance for different feature
combinations on some entities. Not often, but it does happen in real
world use-cases.

[Lew]

Daniel Pitts wrote:
> I have needed multiple levels of inheritance for different feature
> combinations on some entities. Not often, but it does happen in real world
> use-cases.

Can you share a snippet or example to illustrate that, please? I racked my
brain trying to figure out why you'd have > 1 level of '@MappedSuperClass',
although of course multiple depths of inherited '@Entity' chains is common
(though the annotation must be repeated at each level, as discussed upthread).

[Daniel Pitts]

On 1/29/12 10:05 AM, Lew wrote:
> Daniel Pitts wrote:
>> I have needed multiple levels of inheritance for different feature
>> combinations on some entities. Not often, but it does happen in real
>> world
>> use-cases.
>
> Can you share a snippet or example to illustrate that, please? I racked
> my brain trying to figure out why you'd have > 1 level of
> '@MappedSuperClass', although of course multiple depths of inherited
> '@Entity' chains is common (though the annotation must be repeated at
> each level, as discussed upthread).
>

I would, but unfortunately I'm not sure if its a "trade secret" of my
employer ;-)

The basis is that I have a parent abstract class with universal
metadata, then two other abstract classes with divergent metadata
(different schemes for a similar workflow). Then my concrete classes
extend one of those two mid-level classes.

Not a common set up, but it is what was called for in my application.

[Lew]

That's sufficient to make the use case clear, thank you.

The only universally applicable rule in programming is that there are no
universally applicable rules in programming.

[Arved Sandstrom]

I get Daniel's use case. Given the meaning of @MappedSuperclass it's no
more possible to argue against that use universally (as you point out,
Lew) than it is to (categorically) argue against many levels of pure
Java inheritance.

My own use of @MappedSuperclass over the years has been restricted to
defining a set of "administrative" fields that the entities can use,
because all of the tables should also uniformly have these
"administrative" columns. Such fields/columns might include @Id and
@Version, and also created/lastUpdated when/byWhom fields/columns. These
latter are useful for accessible auditing [1]. The @MappedSuperclass
class also becomes the home of entity lifecycle callback methods that
populate many of the "administrative" fields.

For maintenance/ongoing development reasons I'm personally not keen on
using JPA @Inheritance, nor multiple levels of @Entity, nor do I use
@MappedSuperclass for "substantive" fields (I'd prefer not to go the
route of @AttributeOverride and @AssociationOverride either, to
accommodate changes). As you might surmise I like relatively flat,
uninspiring, and "safe" inheritance hierarchies for JPA.

But that's all personal choice. I'll have to admit that if a strong,
reasoned argument were made for a case like Daniel's, that I wouldn't be
able to reject this layered use of @MappedSuperclass out of hand.

AHS

1. By accessible I just mean that "real" DB auditing data is frequently
harder to conveniently get at.

[Lew]

Arved Sandstrom wrote:
> Lew wrote:
>> Daniel Pitts wrote:

>>> Lew wrote:
>>>> Can you share a snippet or example to illustrate that, please? I racked [sic]

>>>> my brain trying to figure out why you'd have > 1 level of '@MappedSuperClass'

... [SNIP] ...

>>> The basis is that I have a parent abstract class with universal
>>> metadata, then
>>> two other abstract classes with divergent metadata (different schemes
>>> for a
>>> similar workflow). Then my concrete classes extend one of those two
>>> mid-level
>>> classes.
>>>
>>> Not a common set up, but it is what was called for in my application.

>> That's sufficient to make the use case clear, thank you.
>>
>> The only universally applicable rule in programming is that there are no
>> universally applicable rules in programming.

... [SNIP] ...

> For maintenance/ongoing development reasons I'm personally not keen on
> using JPA @Inheritance, nor multiple levels of @Entity, nor do I use
> @MappedSuperclass for "substantive" fields (I'd prefer not to go the
> route of @AttributeOverride and @AssociationOverride either, to
> accommodate changes). As you might surmise I like relatively flat,
> uninspiring, and "safe" inheritance hierarchies for JPA.

JPA is best suited for flat, uninspiring, safe modeling overall; the trouble
I've seen in its use comes from a combination of getting too fancy by half
("sesquifancy") and using old-style, pre-JPA Hibernate, or trying to use it
for bulk or set-oriented operations, or trying to do JDBC via JPA which is
utterly stupid. Sets and objects work differently!

Also, the mental model of 'EntityManager' is different from Hibernate's
'Session'. People try to use it monolithically and discover problems like
overfull entity management memory, for which they blame the framework instead
of their own idiocy.

> But that's all personal choice. I'll have to admit that if a strong,
> reasoned argument were made for a case like Daniel's, that I wouldn't be
> able to reject this layered use of @MappedSuperclass out of hand.

> ...

> 1. By accessible I just mean that "real" DB auditing data is frequently
> harder to conveniently get at.

--