Currently most of the metadata exposed by ORM (through the Metadata class in particular) is stored in {{HashMap}}s and {{HashSet}}s. As a result, user code or external integration code based on this metadata may behave differently from one execution to another.

For example if two entities are configured incorrectly in Hibernate Search, during one execution the error would be detected (and thrown) on "entity1" first, and during the next execution the error would be detected on "entity2" first. Which would give the impression of random behavior to the user.

Of course users and integrators could, in most cases, sort the metadata before processing it in order to avoid the issue (see HSEARCH-3182 Open ). But a probably better solution would be for ORM to use a reproducible order to begin with, for example by using LinkedHashMap and LinkedHashSet, or even TreeMap and TreeSet if necessary.

Hibernate Search is impacted in particular by:

• The order of persistent classes in org.hibernate.boot.Metadata#getEntityBindings. The order of this collection has been verified to be unstable from one execution to another
• The order of properties in org.hibernate.mapping.PersistentClass#getPropertyIterator. The order of this collection may be stable from one execution to another, but we should check that.

... but there are plenty of other metadata maps which may impact someone else.

It might be a good idea to wait for ORM 6 before fixing this, especially if metadata changes a lot in that version: the patch will probably be a bit hard to port...

Note: I could not find an existing ticket for this problem with the following query: project = HHH and text ~ 'order' and text ~ 'metadata' order by lastViewed DESC