Follow-up on HSEARCH-3166 Resolved .

It turns out Hibenate ORM metadata is stored in HashMaps, making the iteration order unpredictable, and more importantly different from one execution to another, depending on who knows what (JRE, architecture? I don't know).

Also, this leads to Hibernate Search building different runtime processors (indexing processors, implicit reindexing resolvers): they process the same data, but in a different order.

This may lead to bugs that happen seemingly randomly, because one execution order is fine while the other is not.
Also, this leads to behaviors that are difficult to test, because we need to accept multiple possible scenarios. I've noticed several failing builds already because of this, for example this one: https://travis-ci.org/yrodiere/hibernate-search/jobs/384797427

We should sort the metadata before processing it during bootstrap where possible, so that at least the Hibernate Search metadata and bootstrap process will stay the same from one execution to another.

Note this should of course not hurt performance in any major way.