2

While looking at jhipster, I have stumbled across the following class

public final class AuthoritiesConstants {
    public static final String ADMIN = "ROLE_ADMIN";
    public static final String USER = "ROLE_USER";
    public static final String ANONYMOUS = "ROLE_ANONYMOUS";
    private AuthoritiesConstants() {
    }
}

I was wondering why they did not use enums like for example

public enum AuthoritiesConstants {
    ROLE_ADMIN,
    ROLE_RESPONSABLE,
    ROLE_MANAGER,
    ROLE_COLLABORATEUR
}

Are there any drawbacks using enums?

Zabuzard
  • 25,064
  • 8
  • 58
  • 82
Mathieu Gemard
  • 514
  • 7
  • 11
  • 2
    Not really. They could also have used an enum and added a String field to it, having effectively the same capabilities. (Enums are like classes, you can add methods and fields to them) – Zabuzard Jul 16 '19 at 16:58
  • 1
    Is there a potential to add your own authorities? If so, it couldn't be an enum. – Andy Turner Jul 16 '19 at 17:08
  • Some Spring annotation classes are designed to accept `String`s as their value, not `Enum`s. Maybe that's the case – Nikolai Shevchenko Jul 16 '19 at 17:12
  • 1
    @NikolayShevchenko You can always use `name()` to get a String representation of an `Enum` element, so that's not really a big issue. – Piotr Wilkin Jul 16 '19 at 17:15
  • 1
    @PiotrWilkin you are wrong. Using `.name()` within an annotation would fail with compile-time error `attribute value must be constant`. You can see example here https://stackoverflow.com/q/28031784/2224047 – Nikolai Shevchenko Jul 16 '19 at 17:27
  • @NikolayShevchenko fair enough, didn't think of this scenario. – Piotr Wilkin Jul 16 '19 at 17:31

3 Answers3

5

One possible answer is that enums were introduced in Java 1.5. While this seems like ancient history, some libraries still use string constants or numeric constants for compatibility reasons.

Another possible answer is that those are not really semantically enum elements, but constants used by an external interface and are only ever accessed via their string value. In such cases, using enums and calling name() each time would be redundant.

Other than that, you should never use enums over string constants in such cases.

Piotr Wilkin
  • 3,446
  • 10
  • 18
2

1. It is much like class it’s extend java.lang.Enum so you can’t extend other enum. Another potential problem is you don’t get along with Expression Language (EL) in JSP.

2. There are things that can be done in normal classes but maybe you can not do with enum class because of it is a special class. For example, accessing a static field in the constructor that not possible with enum.

3. When you working with JSP then you can not be accessing enums nor
calling enum constants because it’s not supported (which is possible after EL version 3.0)

These are Major drawback.

.

Amit Sharma
  • 159
  • 2
  • 8
1

If a value is only really meant to be referenced as a String, then I would leave it as a String constant for simplicity's sake.

Enums are more complicated than String constants with additional functionality and nuance. Check out this question about the difference between an enum's toString and name methods.

If you ever need to change the value of a String constant, it is a one-line change. With an enum it can get more complicated due to having separate values for name and toString, and those values possibly being used in conditional logic.

user506069
  • 771
  • 1
  • 6
  • 14