Java enums mutability usecases and possibilities?

Question

I don't know if I'm the only one to know that, but the values of an enum are not implicitly final and can be modified.

  enum EnumTest {
    TOTO("TOTO 1"),
    TATA("TATA 2"),
    ;

    private String str;

    private EnumTest(String str) {
      this.str = str;
    }

    @Override
    public String toString() {
      return str;
    }
  }

  public static void main(String[] args) {
    System.out.println(EnumTest.TATA);
    EnumTest.TATA.str = "newVal";
    System.out.println(EnumTest.TATA);
  }

TATA 2
newVal

These values are oftenly initialized at instance creation (TOTO("TOTO 1")) but, except myself, I've never seen anyone using the final keyword for enum variables that should be immutable. That's not the point of the question, just wondering if I'm the only one aware of this.

What I'd like to know is if there was any usecase to create mutable enums?

And I'd also like to know the limits of what we can do with enums (good practice or not). I've not tested it, but maybe an enum can be injected with Spring beans? At least it seems we can annotate each instance (@Deprecated works fine for exemple), and also the methods.

Using `final` for fields is common practice in enums. – John B Oct 22 '12 at 16:49 — John B, Oct 22 '12 at 16:49

score 11 · Accepted Answer · answered Oct 22 '12 at 18:50

One possible usecase would be lazy initialization (calculate some field values when they are first used, if often they are not used at all), or a "normal" mutable singleton object (like a registry or such).

In most cases, though, enum objects should be immutable, and their fields be final.

score 9 · Answer 2 · answered Oct 22 '12 at 16:50

9

While you point out an interesting fact here, as far as I'm concerned, there is no usecase for mutable enum fields. There are many reasons why making use of this language "feature" ("bug"?) would be a bad idea, not least of which is the potential for confusing other developers.

answered Oct 22 '12 at 16:50

Alex D

29,755
7
80
126

4

I agree in that enums are generally assumed to be immutable and thereby creating mutable enums could lead to misuse. I would suggest that mutable values associated with enums would best be help in an `EnumMap`. That said, I think saying there is "no usecase" is too strong. Enums in practice represent an extension of the singlton pattern (a fixed number of instances) and with that in mind could be used like any other class. I again reiterate that MOST developers are used to thinking of them as IMMUTABLE and therefore mutable enums could lead to maintenance issues. – John B Oct 22 '12 at 16:57
Thank god as they are assumed immutabl there is generally no setter :) – Sebastien Lorber Oct 22 '12 at 20:10
@JohnB, if you can think of a good example of a situation where using an enum with mutable fields is arguably better than any alternative, I would appreciate seeing it as a separate answer. But my answer is still: as far as I'm concerned, there is **no** usecase, at least not a usecase which couldn't be better served with an ordinary `class`. You are right about what enums are "in practice", but conceptually they are closer to a `boolean` (which has a fixed set of 2 possible values) or an `int` (fixed set of 2^32-1 possible values). Can you imagine having mutable fields on `true`? – Alex D Oct 22 '12 at 21:23

score 3 · Answer 3 · answered Oct 23 '12 at 11:40

In response to Alex D's answer and comment, I am taking his suggestion of posting a possible use case. Let's take the old standard enum example of planets from which gravity, etc can be calculated. Imagine that you wanted to maintain the number of human colonies on each planet. Yes you could use a EnumMap, but I could see a case where more and more mutable fields could be needed and having either a seperate map for each value or a separate class to hold the mutable values associated with an enum would be counter-intuitive.

As I stated in my comments, in general I believe enums usually are and should be immutable but I feel that stating that there are no use cases is too strong.

score 2 · Answer 4 · edited May 16 '13 at 17:04

I see no reason to forbid the use of mutable fields in enums. One uses an enum to state that the value of the type belongs to one of a finite (and known) set of possibilities. It does not imply that those values can not have properties that evolve over time.

Some have asked for use cases for such a scenario. One example would be to use an enum type such as ErrorCategory, which would classify an error to one of any number of predefined categories (eg: DocumentationError, SemanticError, LayoutError...).

Suppose those ErrorCategories have properties such as requiresInstantIntervention or shouldFailBuild. I can imagine that the value of those properties could change over time or that they can be user-configurable.

I realize that there are (many) other ways of implementing this (such as indeed EnumMaps mentioned above) and one can always argue about style, but for me, such a use of enums is not wrong in itself. As enums are reference types in java, behaviour of == remains the same as if there were no mutable properties in the first place.

score 2 · Answer 5 · edited Mar 15 '16 at 15:29

2

An enum instance is a public static final Field of the enum class. So if it's mutable, you may modify its state in another thread. This may not be what you want and may cause problems if you don't realize this.

edited Mar 15 '16 at 15:29

Louis CAD

10,965
2
39
58

answered Oct 27 '15 at 07:18

Adrian Liu

385
3
13

score 1 · Answer 6 · edited Oct 21 '19 at 16:12

Correct me if I am wrong but an Enum is the easiest (and more importantly perhaps the safest) way in Java to actually have a true singleton throughout the lifetime of the application (if we cannot use the CDI), as using the standard static getInstance() method pattern could still produce multiple instances of the same class if implemented too naively.

[Likewise implementing the Serializable could also potentially lead to producing more than just one instance, whereas the Enum already takes care of it for us without unexpected results and boilerplate.]

Also, the documentation says clearly that the Enum type is so much more than just constants. So I would say that whenever it's absolutely necessary to have a true singleton in the app, an Enum (even mutable), might be considered a fair use.

However, it seems to me that this question inevitably tends to be a bit on the opinionated side and cannot be answered completely unbiased as there are developers who favor immutability (and I am not saying that there are not good reasons for it) but also developers who are not that strict in this regard and basic documentation skill can be sometimes just as important as the code itself (what prevents us from highlighting the fact that the Enum constants' internal states are actually mutable in the javadoc?).

I find this large paragraph rather hard to follow; is it an answer, or a new question? Questions should not be posted as answers; [Stack Overflow is not a forum](https://meta.stackexchange.com/questions/92107). If it *is* an answer, would you please break it up into paragraphs to make it easier to read? — Tom Zych, Aug 07 '18 at 21:44
It's an answer. I will break it up tommorow, yes, it was quite long, sorry about that. — Vítězslav Cibulka, Aug 07 '18 at 21:55

score 0 · Answer 7 · answered Aug 07 '18 at 19:22

I use a mutable enum for handling serialized numeric values outside of my control that I want to preserve when using and relaying. e.g.

VALUE_A = 1
VALUE_B = 13
VALUE_C = 17
VALUE_UNRECOGNIZED

e.g. What if I receive serialized value of 61? I don't recognize it, so I don't have an enum constant for it, I don't otherwise deal with it, but I don't want to fail it: I want to preserve the serialized value and relay it along.

Perhaps the canonical approach might be to create a new class with two fields: an immutable enum and the original value, but, IMHO, that seems more cumbersome.

score -3 · Answer 8 · answered Oct 22 '12 at 16:45

-3

What I'd like to know is if there was any usecase to create mutable enums?

The enum constants are not themselves mutable, their fields are mutable.

answered Oct 22 '12 at 16:45

Miserable Variable

28,432
15
72
133

1

That's what he means, as I understood it. – Louis Wasserman Oct 22 '12 at 16:47
Yes that's what I mean, but the "general" usecase is to create immutable enums, but nobody useses "final" – Sebastien Lorber Oct 22 '12 at 16:47
That's because there is rarely an `enum` with a `public` field or a public method to change a field IMHO. But I agree that the fields should be declared `final`. – Miserable Variable Oct 22 '12 at 16:53
Sounds like OP well-understands that and is asking why the language is designed to support that, so DV'ed as not answering question. – djechlin Oct 22 '12 at 18:47
1

@djechlin enjoy! In my line of work being precise is more important then supposedly understanding. Maybe you use tools that understand your intent – Miserable Variable Oct 22 '12 at 18:49

Java enums mutability usecases and possibilities?

8 Answers8

Linked

Related