I'm curious why Hibernate limits Entities to having only a single superclass? In my case I've got class DefaultTheme which extends AbstractTheme and implements Theme. This is completely legal from Java's point of view but Hibernate won't let me map it.

I'm just curious as to why this limitation exists -- I didn't see any sort of explanation on the online documentation.

Thanks,
Gili

Absolutely no idea what you are talking about. You realize that you say "hibernate allows only one superclass", and then proceed to illustrate this "limitation" with an example where you have only one superclass?

In hibernate terminology, both classes and interfaces count as "superclasses" hence my example class has two "superclasses" -- at least that is what I read.

My point is, what happens when you have a class that implements multiple interfaces? I was told that one couldn't map that using Hibernate and you could only choose one interface as your superclass.

Gili

Again, I have no idea what you are talking about. Why do you think Hibernate won't let you map what you posted in your initial post?

I was told by Emmanuel that a mapped entity may only have one mapped super-entity. Is that not correct?

Gili

Well "a mapped entity may only have one mapped super-entity" is certainly different than "limits Entities to having only a single superclass"...

Sure Hibernate lets you have an interface act like a superclass from the perspective of the mapping, but that by no means indicates that you have to map all the interfaces a given class implements.

Java does only allow single class super-typing. The fact that you've asked Hibernate to deal with some interface specially in thei regards doe not change that fact.

Or am I still missing something in your question?

I refactored my class structure (removed the use of Generics) so I no longer have a decent use-case to show as an example. If I run into this issue again I'll let you know.

In my original use-case, I absolutely needed to have two mapped superclasses (one an interface, the other a class) but as already stated it was a bad class hierarchy to begin with and was scrapped.

Gili

Why?

DefaultTheme extends AbstractTheme<Theme> implements Theme
{
Theme getParent();
}

AbstractTheme<SelfType> implements GenericTheme<SelfType>
{
SelfType getParent();
}

Theme extends GenericTheme<Theme>;
GenericTheme<SelfType>;

Basically Theme needed to be mapped because DefaultTheme's "parent" property returned it. AbstractTheme needs to be mapped because it is the superclass of DefaultTheme and we needed to map it in order to map the hierarchy from GenericTheme through DefaultTheme.

Anyway, as you can tell, the hierarchy is overly complex and confusing which is why I dropped it.

Gili

My point was simply that you can just map AbstractTheme and not Theme. DefaultTheme.parent can be mapped as AbstractTheme also, leaving the exposed type as Theme (an AbstractTheme is still always a Theme).

Unless I am missing something here, I still do not see any *need* to map Theme.

I didn't want to return AbstractTheme because it was a Generic class with five parameters, so I'd end up saying something like this:

AbstractTheme<?, ?, ?, ?, ?> result = theme.getParent();

Furthermore, AbstractTheme did not extend Theme because if you read above Theme has no type parameters whereas AbstractTheme did. Theme was basically a "typedef" that filled in the type parameters.

I ended up dumping Generics because it got too complex.