Constants of non-priminal types

Question

In Java, constants are declared with sequences of Keywords static and final.

When we have public static final int UM = 1; "makes sense to "call it constant, since its value cannot be changed.

Now, speaking of primitive types, it still "makes sense" to call constant, since its attributes can be changed through methods?

The only thing that stays constant is the reference, not the values of the attributes.

---

Until today I did not need to create a constant of a primitive type (I confess that I did not see sense for it), but seeing that code in Github came to me the doubt.

Answer 1

Not.

Maniero put an answer that explains the technical reasons for this. I will put here the reasons why what the author of the code did is wrong.

The relevant part of the code mentioned is this:

private static final Random RANDOM = new Random();

The keyword final ensures that whoever contains a value or reference will not be able to change it after initialization - but this is unnecessary in this case, as the above field is already private. The author of the code is only protecting his code against the author himself. Because it is private, the field could only be changed by class method (which is a decision of who to keep the code), or by reflection (which is the Cheat supreme anyway).

That seems more overengineering, probably the fruit of conditioned behavior. This occurs, for example, when we hear things in college like "always declare something like this," "always use this pattern," etc. and we don’t question why.

---

As for the original doubt, whether the object would be a true constant, since its members could still be changed... As Maniero said, perhaps the wish is to have something immutable. It does not seem to me to be the purpose of the code relevant to the question, because what the code proposes to do is to give a black box for the generation of (pseudo-)random numbers. In any case, the object RANDOM will change its internal state at each number obtained.

And finally, speaking conceptually... If you have a constant, static object that has immutable members, you could cut the intermediary and declare the same attributes of the immutable object in the class that holds its instance. So you would have a shallower tree. I think that save some very specific need it would be more straightforward and easy to understand.

Answer 2

First, in my opinion Java has no constant, has static fields that can not have their value changed after defined, which is static will always occur before being accessed the first. I don’t know if Java has any specification that indicates the exact timing of the assignment. So for me the term constant can’t even be used in the case shown in the question, it’s a static variable immutable.

In C# there is immutable variable, static or not and constant that is always static and guaranteed to be the same in every execution (if the programmer does not shave and use constant as if it were immutable variable). Of course constant must be solved at compile time always, it cannot be initialized after, so not all types can be used.

If that doesn’t answer the question as I would wish, then I would say that a type by reference, called in the question of not primitive^*, placed in a variable final, that makes it immutable, could be called constant, regardless of whether it is static or not, after all if the term is used wrong in static variables, I do not see why not use in instance variables. So it would be the value indicated by that identifier, which is the reference for an object is "constant", but the object pointed by it can be variable.

Having the ability to vary is different from be a variable. Just as not having the ability to vary cannot be automatically considered constant.

Immutability is different from constancy. Although I knew that some people have another understanding. I think mathematics itself does not define well what is a constant. There is something that does not vary in the algorithm and something that never varies, that I think is the true constant.

I didn’t get into the merits of it being unnecessary in the code linked in the question why it is not her focus, but if you want to know has the answer of Renan that is well in the style that I like, Desmistifying myths.

^* This is going to be messy when future Java allows non-priminal value types, which is why I tell you to always conceptualize right, even when you don’t seem to need it