Software Engineering
java programming-practices enum
Updated Wed, 13 Jul 2022 15:21:35 GMT

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


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

Solution

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.





Comments (5)

  • +2 – Good points, but you're forgetting about the case where someone decides to change the name of one of the enum entities (HEARTS to Heart or something in your example) and suddenly everything breaks again. — Dec 16, 2014 at 14:01  
  • +1 – @ScottWhitlock Not if you account for that, though they could decide to rename it entirely. They could accidentally delete the database and delete the project too, but we can't account for every possible incident here. — Dec 16, 2014 at 14:09  
  • +5 – @Neil - true but we're trying to play the odds here. I'm not familiar with Java enums, but in C#, I explicitly set the values for enums if the values need to have meaning outside the program (such as in a database) (e.g. Hearts = 1, Diamonds = 2, etc.). Since that's not the default way to use an enum, it should give a later editor pause. Plus a comment noting where else these are used is handy. — Dec 16, 2014 at 17:34  
  • +1 – @ScottWhitlock That is definitely the better way to go about it in order to avoid such problems. Though supposing you did that, you still see 1, 2, 3, 4 on the database or serialized in some file. Not ideal from a maintenance standpoint any way you slice it. — Dec 17, 2014 at 08:50  
  • +2 – If I may add, if the enum is serialized as string and someone changes the name of an enum, during deserialization the error will be during the parsing. If the enum is int and someone changes the definition, the error will be further down the line, during processing, which will be harder to diagnose. CC @ScottWhitlock. — Jun 25, 2018 at 05:49  

References