Sun (and now Oracle) maintained a document titled Code Conventions for the Java Programming Language. The last update to this was in '99, but the essence of the style guide line lives on.
Chapter 9 covers naming conventions.
For an identifier type of 'constants':
The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_"). (ANSI constants should be avoided, for ease of debugging.)
The examples given:
static final int MIN_WIDTH = 4;
static final int MAX_WIDTH = 999;
static final int GET_THE_CPU = 1;
In a more recent document - its slipped in there. From Variables (The Java Tutorials > Learning the Java Language > Language Basics:
If the name you choose consists of only one word, spell that word in all lowercase letters. If it consists of more than one word, capitalize the first letter of each subsequent word. The names
currentGear are prime examples of this convention. If your variable stores a constant value, such as
static final int NUM_GEARS = 6, the convention changes slightly, capitalizing every letter and separating subsequent words with the underscore character. By convention, the underscore character is never used elsewhere.
Many static analyzers for Java seek to enforce this. For example checkstyle enforces:
Checks that constant names conform to a format specified by the format property. A constant is a static and final field or an interface/annotation field, except
serialPersistentFields. The format is a regular expression and defaults to
This really boils down to the conventions of the community writing the code... and ideally keeping it the same.
The examples above are given as
static final ones which are likely derived from the C conventions for
#define - which like C, are replaced in the code during compilation rather than at runtime.
The question that then should be asked is "is this behaving like a constant? or is it behaving like a write once field?" - and then following the conventions accordingly. The litmus test for such a question would be "If you were to serialize the object, would you include the final field?" If the answer is that it is a constant then treat it as such (and don't serialize it). On the other hand, if it is part of the state of the object that would need to be serialized, then it isn't a constant.
Whatever the case, it is important to stick with the code style however right or wrong it is. Worse problems erupt from inconsistent conventions within a project than merely something that offends the eye. Consider getting some static analysis tools and configure them to maintain consistency.