The processForeignKeys() method of org.hibernate.cfg.reveng.ForeignKeyProcessor uses several HashMaps to store information about foreign keys. It is the "natural order" of those HashMaps that defines the order in which the corresponding Set<X> properties will appear in the generated POJO source's full constructor.

While the order that results from this generally stays the same over multiple runs of reverse-engineering (as long as the hash of the foreign key name, which is used as key, is stable), it might change in an annoyingly complex way if there are "To-Many" foreign keys added or removed to/from the database table that the HashMap's actual capacity and hence natural order differs from the previous reverse engineering run in a non-foreseeable way.

For me, this is currently an issue because I have several tenants using multiple instances of the same database, where I need to run reverse-engineering on each of them because Tenants can have additional tables in their copy. I always make sure that the To-Many-sets of those additional foreign keys are "<set excluded=true/>" in the reveng configuration, because I need the method signatures of the POJOs to be consistent across all tenants for my application to work.

Now, when a given table in Tenant A's schema has for example 12 incoming foreign keys, but 13 in Tenant B's schema, the resulting POJO class constructors will have a completely different order of the Set parameters in the full constructor, if the additional entries force the HashMap to use a different number of buckets.
Even when the actual number of sets in the generated POJO sources is equal due to excluding sets from the reveng, this effect will still occur because the HashMap is populated without consulting with the reveng restrictions.

This issue is present in the current master and I think it has always been like this. In an attempt to fix this for me, I swapped those 3 HashMaps for TreeMaps - see the commit on my GitHub fork:
https://github.com/hannibal218bc/hibernate-tools/commit/38086a926ab6c5e94cee5587fd4c123bf4443305

... but doing that means that pretty much all full constructor signatures will be different to the previous HashMap implementation, which might not be acceptable for the general public. Also, testsf

A cleaner approach would probably be to have processForeignKeys() be aware of <set exclude="true"/>. This would keep the hash-ordering at least consistent, even when non-source-changing foreign keys are added or remove.
Still, adding a foreign key with a corresponding set could result in all the set parameters getting completely shuffled.

Whats your opinion on this? Is this an issue you would consider to work on?
I'll be happy to supply a pull request, but I'll need some guidance on what an acceptable solution would be.