Constants of non-primitive types

No.

The bigown has posted an answer that explains the technical reasons for this. I'll put here the reasons why what the author of the code did is wrong.

The relevant snippet of code mentioned is this:

private static final Random RANDOM = new Random();

The keyword final ensures that whoever contains a value or reference can not change it after initialization - but that is unnecessary in this case because 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 the class itself (which is a decision of whoever maintains the code), or by reflection (which is the supreme cheat anyway).

This seems more excess engineering , probably due to conditioned behavior. This occurs, for example, when we hear things in college like "always state something like that," "always use that pattern," etc. and we did not question the reason.

As for the original doubt, if the object would be a true constant, since its members could still be altered ... As the bigown said, perhaps the desire is to have something immutable. It does not seem to me to be the purpose of the code relevant to the question, since what the code proposes to do is to give a black box for generating random (pseudo) numbers. However, the RANDOM object will change its internal state to each number obtained.

And finally, speaking in a conceptual way ... If you have a constant and static object that has immutable members, you could cut the middleman and declare the same attributes of the immutable object in the class that holds your instance. So you would have a shallower tree. I think save for some very specific needs this would be more straightforward and easier to understand.

First, in my understanding Java has no constant, it has static attributes that can not have their value changed once they have been defined, which is always static before being accessed first. I do not know if Java has any specification that indicates the exact timing of the assignment. So for me the constant term can not even be used in the case shown in the question, it is a static variable immutable . / p>

In C # there is an 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 barbeque and use constant as if it were immutable variable). Of course constant must be resolved at compile time always, can not be initialized afterwards, so not all types can be used.

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

Being able to vary is different from being a variable . Just as not having the ability to vary can not be automatically considered constant.

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

I did not merit this being unnecessary in the linked code in the question because it is not the focus of it, but if you want to know there is Renan's answer that is well in the style I like, demystifying myths.

* This will make confusion when Java 10 allows non-primitive value types, so I say forever to conceptualize right, even when it seems like it does not need