I get sick of this line of thinking.

Sounds like you've had a bad day =) If I contributed to that, then I'm deeply sorry.

Reading your comments, I can only agree wholeheartedly. And you're right, Hibernate did say "define/". In my mind, I got hooked up with the word "override". So I was wrong saying Hibernate was wrong.

You seem to think that not having a version attribute automatically enables pessimistic locking? Or I have misread you - again! =) Let's just be clear, JPA 2.1, section 3.4.3:

Pessimistic locking may be applied to entities that do not contain version attributes.

"May" is not a requirement as you most certainly know having your comment about specifications fresh in my mind. And in the end, I am the judge deciding whether or not I want to use pessimistic locking. That lock has to be acquired explicitly or am I completely lost? With no version attribute, the only thing left is the "assumption" that the database use an read-committed isolation level (section 3.4). So to summarize, there is a third strategy: none at all. There's even a LockModeType for that!

You are right about my model, it is fucked up. The "model" is used in a suite of Java EE test code that I write - not in a real world application. My test cases assert and demonstrate different read phenomenas using a high-level thread scheduler and different strategies. I can promise you that in this test suite, having a non-versioned superclass makes a lot of sense. But hey, I have never had the need to mix different strategies in the same entity hierarchy in a real world application. So don't lift a finger yet if I'm the only one asking.

Interestingly, you cannot decide that a superclass has optimistic locking (and thus a version property) and in a subclass deny that and only allow pessimistic locking. That would be against the Liskov substitution principe as the version is a state of the superclass.

But I didn't add a version attribute to the superclass. It was added state and behavior of my subclass.

Even if I had done so, then the subclass would "inherit" the version attribute like he do with all the rest. For example, my subclass doesn't add an @Id field. But that doesn't mean the subclass "remove" the entity id. Sufficient it is that the superclass is the only one declaring the field!

It feels wrong to allow one way and not the other.

Sure, had it been that way, then I feel you 100 %. Therefore, I don't use instanceof in Object.equals(), instead I prefer getClass() even though it will brake Liskov's substitution principle. I guess sometimes, one must pick his poison =)