2

When defining a variable of a type of one of the Atomic… classes, and marking it final to avoid replacement, is such a variable considered to be a constant?

The object reference contained in the named variable will not change, because of the final. Yet the Atomic… object is really just a protective wrapper around a payload, a value that may well be changing.

The point of my question is the Java naming conventions. By convention, constants such as a final member field or final static should be named in all-uppercase. So I came to wonder about how to name the object reference of a Atomic… such as AtomicInteger.

Here is a contrived example class.

➥ Should the final private AtomicInteger be named count or COUNT?

package work.basil.example;

import java.util.concurrent.atomic.AtomicInteger;

public class CountUp
{
    final private AtomicInteger count;  //  `count` or `COUNT` ?

    public CountUp ( )
    {
        this.count = new AtomicInteger();
    }

    public int increment ( )
    {
        return this.count.incrementAndGet();
    }

    public int getCount ( )
    {
        return this.count.get();
    }
}

You might think this Question of duplicate of ones such as Should a “static final Logger” be declared in UPPER-CASE? or Should I use upper-case naming to declare java constant variables?. But no. I believe the nature of Atomic… objects puts a spin on the issue.

My first thought is: Context is everything. In conversation regarding specifically thread-safety issues, I would refer to the AtomicInteger as a constant. But in the context of the business logic, the payload of the Atomic is meant to be changing. I would not consider an Atomic to be effectively a constant. So I lean to naming with the usual camelCase.

Basil Bourque
  • 303,325
  • 100
  • 852
  • 1,154
  • 1
    Your use of AtomicInteger in that sample should not be considered a constant. For one thing, you can increment it. – NomadMaker Feb 09 '21 at 03:18
  • I have not encountered final instance fields being capitalized regardless of `Atomic`. – chrylis -cautiouslyoptimistic- Feb 09 '21 at 03:32
  • Since we're talking about convention: `final private AtomicInteger` -> `private final AtomicInteger` – Spectric Feb 09 '21 at 03:35
  • 1
    Imo, if the essence of the variable or class can be changed, then it should not be considered a constant. This would pertain to mutable classes where you don't want the reference to change but the contents may vary throughout time. It those cases I would not capitalize it. – WJS Feb 09 '21 at 03:39
  • @NomadMaker The twist here is that the final variable `count` never changes its actual contents. The pointer to the `AtomicInteger` always has one permanent value, always pointing to the very same `AtomicInteger` object. The object reference is literally constant. But this constancy is shallow, as its payload is mutable. – Basil Bourque Feb 09 '21 at 03:56
  • 1
    I usually only use all-uppercase for *static* final fields, so in this example: definitely no. I think that’s a rather common convention. – Axel Feb 09 '21 at 05:35
  • @Axel Good point, the Google code guidelines I quoted below actually say that all upper case should only be used for static immutable fields. – markspace Feb 09 '21 at 14:43

1 Answers1

4

Google's code style guidelines says that final fields that reference a mutable object are not considered "constants" and are not capitalized.

https://google.github.io/styleguide/javaguide.html

To quote section 5.2.4 Constant names:

But what is a constant, exactly?

Constants are static final fields whose contents are deeply immutable and whose methods have no detectable side effects. This includes primitives, Strings, immutable types, and immutable collections of immutable types. If any of the instance's observable state can change, it is not a constant. Merely intending to never mutate the object is not enough.

Some examples from that section:

// Not constants
static String nonFinal = "non-final";
final String nonStatic = "non-static";
static final Set<String> mutableCollection = new HashSet<String>();
markspace
  • 10,621
  • 3
  • 25
  • 39
  • Thanks. The phrase “deeply immutable” solved it for me. The programmer reading an all-uppercase field name should be able to rely on the fact that nothing about its contents will ever be changing. – Basil Bourque Feb 09 '21 at 04:00