I completely agree that relying on specific subtypes unnecessarily is bad design, but in the event the subclasses (in three separate hierarchies) in the application I'm working on actually do have different fields and behavior; they're not simply the equivalent of different PLAF implementations of a generic Button class, and while I used collection-valued fields in my example, I have a couple of instances where an entity needs simply a single-valued association to a particular subclass, which also doesn't work.

The simplest example is that AccountingEntry has optional facet fields linking it to an order, customer, etc., and each order, when placed, generates exactly one instance of exactly OrderChargeEntry. The only way in Hibernate to express this relationship is to make the field a generic AccountingEntry, which either breaks type safety in the Java API or requires explicit runtime casting, which itself is sometimes dodgy because of the unexpected implications of dynamic proxying.