Creating a sorting for the mappings seems like a good idea.

My rust code sorts them like follows:

N is the number of namespaces. This is a constant and fixed for any mapping.
Option<T> gets sorted as follows: first come all the None variants, then all the Some(T) variants, sorted by T ofc.
Strings sort like the bytes of a UTF8 representation would sort. Since all Strings in mappings are just ASCII, I think relying on java's String sorting is fine for this (java actually sorts according to the chars inside the string, since we're not leaving the code point range of a char (where we'd have two chars encoding a surrogate pair), we're fine).
For classes, sort them lexicographically as if they were a list with length N of elements of type Option<ClassName>. The first element of the list is the name in the first namespace, the second one in the second namespace and so on. ClassName is a String.
- Inside each class sort the fields first by their descriptor (again a String), then by their names (again a list of options like with classes)
- The same goes for methods.
  - For parameters, sort by the index (as a number) and then by the names as a list of options like the classses.

Also relevant is the order in which the things are written out:

It would be nice to get the same sorting order with java.

One note by me: For comparing my results with the results of the buildscript, I read, sorted and wrote the output once.

Also my code has forced sorting in the actual mappings writer.

sort mappings #163

Description