Is it better to use strings or int to reference enums outside the java part of the system?

Question

We were having a discussion at my work about the use of enums in Java.

A coworker was arguing that when using enums on the server-side, whenever required we should use string to reference to it (for instance when sending data from JS to the server or when storing in the database), arguing that this is much more clearer for the developer and also arguing that it would fail fast in case of typos.

I always used integers to identify enums in these cases, because it would be immutable identifiers and would not have case and typo problems (even though if a dev made the mistake of using the value 2 instead of 1, it would not fail fast).

Being very analytic about these arguments, I would say that using strings is better, but I get a strange feeling about it (as if it was not a good approach).

Is there any best practice regarding this discussion that could guide me?

Edit: Whenever it is possible, we use the enum itself, so all our Java code uses the Enum. By "reference to an enum" I mean: referencing the value in the enum when exchanging data from JavaScript to the server or storing data in the database

Answer 1

Good question. The use of enum in Java is primarily meant to handle information that is somewhat categorical in nature. The classic example being using enum to handle the four types of suits that a card could have. It provides all the performance advantage of using an integer and it is also clear in your program.

So outside of Java, why wouldn't you continue using an integer? Perhaps you don't have enum types outside Java, though that doesn't mean you can't continue using integer for performance purposes, right? Yes, that's completely true, though consider what happens when you add a new enum value. If you don't add it to the end, all the other enum values after the new value will be increased by one. Well we'll just specify the number so it can't change or we'll always add it to the end. Are you confident that your fellow coworkers will always do right by that? Meh? Probably? Hopefully? Maybe you're not 100% on that. Keep that in mind for a second.

Your boss tells you that there's a mess at the client using your software after the last update. Now all entities X act like they were assigned enum value Y even if they were really assigned Z. You check the repository and yes, someone added a new enum value and didn't follow your guidelines as you asked them to. Now you have the added complication that on the database it is written 4, when it really should be 3, excluding records that have been inserted prior to the update which really are 4. What enum value pertains to 4 anyway? Isn't it Y? You can't remember. You need to check the program to verify. Simply put, it's a mess.

If instead, your database wrote "HEARTS", "DIAMONDS", "SPADES", "CLUBS", you've lost little in terms of space and gained so much. It's true we're talking about a minor performance hit, but you really should not be accessing the database that often to make a difference. As for space, leave that to the systems administrators (not. your. problem.).

If you've made a simple program that is easy to make changes to, you've done yourself a favor in the long run, trust me. This aspect of it is no different in my humble opinion.

Answer 2

I agree with Neil's answer, but just an addition:

In java enums are Objects, so they can have fields and methods. So you can give each enum some manualy specified value and when referencing it for outside work, use that value instead.

It will survive both adding/removing/reordering and changing name of enum instance. But you will have to write serialization/deserialization logic for enum fields instead of using automagic available in many tools. (Its easy, but its aditional work).

And you must keep those values unique manually (but that's same in C style enums), and you can write test to check that.