# Is it important for reflection-based serialization maintain consistent field ordering?

I just finished writing a packet builder that dynamically loads data into a data stream for eventual network transmission. Each builder operates by finding fields in a given class (and its superclasses) that are marked with a @data annotation.

When I finishing my implementation, I remembered that getFields() does not return results in any specific order.

Should reflection-based methods for serializing arbitrary data (like my packets) attempt to preserve a specific field ordering (such as alphabetical), and if so, how?

• I tweaked the wording of your question to attempt to make it more broadly applicable, and less localized to your specific implementation. – user1430 Jul 3 '13 at 5:40
• I declined the suggested off-topic close vote; yes, on the surface this is not about games, but the requirements of and best way to deal with serialization for game networking is different than what I would recommend for HPC or Web interfaces. I would answer this question differently here than I would on StackOverflow. – Sean Middleditch Jul 3 '13 at 18:31
• @SeanMiddleditch and off-topic-suggesters: It was originally about packet handler for a game. Josh edited and generalized it. – Matchlighter Jul 3 '13 at 21:29

If you have any dependency on that ordering (as in, you enumerate the results of getFields() on the receiving end and deserialize each field in succession), you had best make sure you have control over it, or you will end up tracking down a very subtle-looking bug a long way in the future. Then you'll really kick yourself. This is the most important reason to order the fields, but it will also be useful for a programmer to know the expected ordering when he or she works on the system, or its data.
It's usually hard to get reflection APIs to return results in code-declaration order. So any ordering method (alphabetical, size, name hash, whatever) will have some disconnect with the layout of the structure as read by a programmer. At least with a defined, enforced ordering you know what that disconnect will be. The ordering of getFields shouldn't be relied on and could potentially change underneath you when you least expect it.