Sorry for being condescending. It is clear that generics came after hibernate was invented and now it is a tough job to make it work perfectly. I would have loved that sun or later oracle would support this better OOTB in the JDK. However, from that point we have pretty much low level APIs. I have seen so many bugs where programmers start to deal with getTypeParameters() or in general working with java.lang.reflect.Type without understanding the underlying generic type-system what is actually a complex animal.
Also I do not want to play the smart guy: I wanted to port my reflection and bean introspection code in my open-source project to Java5 and generics those days in one weekend and actually it took me almost a year to get it done covering all scenarios I am aware of.
You pretty much have to reimplement what javac has already done based on the reflection API.
I am already active in various OSS projects and will get totally lost if I also start hacking in hibernate. So sorry to say so but I will not find the time in the next future to provide PRs for you.
You can copy my source-code if you like it without restrictions and my full permission from here or get inspirations from it if you like it:
https://github.com/m-m-m/util/blob/master/mmm-util-core/src/main/java/net/sf/mmm/util/reflect/impl/GenericTypeImpl.java
Also you can dig in guava source code that also does a good job on this task.
Simply accept that resolving a type in a generic way to an actual class in java is nothing you should implement here and there. However, this is what IMHO is currently done in hibernate code base.
I do not want to argue if something is a bug or not. But users of the JPA will use the potential of the Java language and expect the JPA vendor to deal with that. Sorry for being harsh in my comments - please ignore my ignorance and just think about all the hibernate users that do not want to see such stacktraces.