Why are Presence Type/Show not in RFC order

Out of interest, I wonder why the Presence.Type and Presence.Show enums in Tinder are not in the same defined order as the RFC6121 http://xmpp.org/rfcs/rfc6121.html#presence-syntax-type I wonder, because I an integrating with an external app that has defined a C enum with available = 0, error = 1, 2 = probe etc, which seemed a logical way to do it.

Just means I have to write a mapping - yes, I know it’s not a big issue, just that it’s odd to try to understand why the Java enum is written the way it is.

I have filed this as a task for Guus to check this TINDER-64

I believe that the current order of these Java enumeration is defined by chance. If anything, it should follow the XSD definition as provided in http://xmpp.org/rfcs/rfc6120.html#schemas-client. In the TINDER-64 I’ve explained that I am not comfortable with such a change in Tinder, as it’s likely to cause more

trouble (backwards compatibility in third party implementations) than do any good.

In Java we don’t need to refer to the ordinal of an element in an enumeration. Although we can refer to those ordinals (referring to “available” using the value “1”), it’s considered bad practise. Why use “1” if you can use the identifier “available” directly?