1

Let's take a look with my enum definition here:

public enum Day {
    MONDAY(1),
    TUESDAY(2),
    WEDNESDAY(3);

    int index;

    Day(int i) {
        index = i;
    }

    public void setIndex(int index) {
        this.index = index;
    }

    public static void main(String[] args) {
        Day x = MONDAY;
        Day y = MONDAY;
        x.setIndex(2);
        System.out.println(y.index);  // Ouput: 2
    }

In general, I know we should not implement code like that. To prevent this, why java don't use final for final int index like Java treat with interface's properties. Does anyone can explain that?

hoang
  • 1,444
  • 11
  • 19
  • 1
    this will help [Are enums allowed to have setters in Java?](https://stackoverflow.com/questions/15302188/are-enums-allowed-to-have-setters-in-java) – deadshot Aug 22 '20 at 05:06
  • A _property_ is defined in Java by its getters/setters. Interfaces can't have _instance fields_ at all; they can only have constants. – chrylis -cautiouslyoptimistic- Aug 22 '20 at 05:17
  • 1
    One thing that making all enum fields `final` will prevent us from doing is [enum singletons](https://stackoverflow.com/questions/26285520/implementing-singleton-with-an-enum-in-java), though I don't think this is too much of a problem. We can still write singletons with a class. – Sweeper Aug 22 '20 at 05:51

2 Answers2

4

Questions like "Why Java doesn't force to use of final for enum properties" have only one correct answer:

Because the Java designers did not design it that way.

We can only speculate as to why they didn't design it that way. The only people who really know the actual reasons are the designers themselves. And the chances are that even they wouldn't be able to remember all of the details of their decision making. (I wouldn't be able to.) There could in theory still be minutes of design meetings sitting in the bottom of someone's filing cabinet, but they are not accessible to us ... now.

My speculation is that the designers would have thought of plausible use-cases where enum values with mutable properties would be useful. And as @Sweeper points out, enum-based implementation of the singleton design pattern is one such use-case. Even the example that @aeberhart quotes in his answer can be read another way:

While fields of an enum do not have to be final, in the majority of cases we don't want our labels to change.

implies that in a minority of cases, they could want the labels to change. That's an argument for NOT requiring the label field in the example (and fields in general) to always be final ... at the language level.

To generalize, it is not a good thing for a program language design to not support (or forbid) constructs and usage patterns just because the designers don't like it. Or just because certain (so-called) experts endorse them as "best practice".

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
0

It is best practice to use final, but (unfortunately) not enforced by the compiler.

This tutorial (https://www.baeldung.com/java-enum-values) states this as follows:

"Our label field is final. While fields of an enum do not have to be final, in the majority of cases we don't want our labels to change. In the spirit of enum values being constant, this makes sense."

aeberhart
  • 744
  • 1
  • 4
  • 15
  • 1
    Please read take time to read: ["No Best Practices"](https://www.satisfice.com/blog/archives/5164) – Stephen C Aug 22 '20 at 06:01
  • @StephenC Interesting read. I suppose one can refer to this article when naming all variables with uppercase letters ;) – Scratte Aug 22 '20 at 07:26
  • You are missing the point. Naming variables is about following Style Guides conventions or not ... not (so called) "best practice". (And I can give you scenarios where following those conventions is NOT the right thing to do ... *proving* that they are not "best practice".) – Stephen C Aug 22 '20 at 07:54
  • 1
    The point is that almost *nothing* in computer science / computer programming / software engineering is *really* best practice. – Stephen C Aug 22 '20 at 07:56
  • @StephenC I'm sorry. I think my comment came off differently than I intended. I was just being annoyingly pedantic :) – Scratte Aug 22 '20 at 09:42