Naming convention for getters/setters in Java

Question

if I have the following private member:

private int xIndex;

How should I name my getter/setter:

getXindex()
setXindex(int value)

or

getxIndex()
setxIndex(int value)

EDIT: or

getXIndex()
setXIndex(int value);

?

Answer 1

The correct answer is

getxIndex()
setxIndex(int value)

if you want them to be used as properties according to section 8.8: Capitalization of inferred names of the JavaBeans API specification (e.g. access them via ${object.xIndex} in a JSP.

Answer 2

In accordance with JavaBeans API specification from 1997 it should be as Thomas Einwaller describes.

private int xIndex;
public int getxIndex() { return xIndex; }
public void setxIndex(int xIndex) { this.xIndex = xIndex; }

This is unfortunate, getx and setx are not words, making for the rare case were code generated by IntelliJ also gets a warning by IntelliJ. So while this conforms to the JavaBeans specification, it violates the convention for naming a method. In the rare case when this would form a word or acronym it would be disinformative, eg the methodsetiMessage most likely has nothing to do with SETI. Using the only valid measurement of code quality (WTFs per minute), I assess that this is bad code.

It all comes down to this sentence of the JavaBeans specification:

However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone.

Exactly what kind of use of all upper-case names this refers to is unclear to me. Field names should, according to convention, be camel cased. It seems to me that we generate unconventional method names in order to support unconventional field names as decided by a 20+ year old document.

It should also be noted that even though it seems to be an overwhelming support for the JavaBeans specification in tools, it is not exclusively used. Eg. Kotlin will not recognize xIndex as a property in the above example. Reversely, the Kotlin property var xIndex = 0 will result in the Java methods getXIndex and setXIndex. This seems to be a bug according to the JetBrains support, but I fail to see how they can fix that without making a breaking change.

Some tools that does support the JavaBeans specification has not always done so, eg Jackson and Swagger Code Generator have been patched to conform to it. Even though IntelliJ generate accessors according to the JavaBeans specification, the example in the documentation differs from it. Probably because people don't know about the standard and naturally prefers the normal method naming convention.

So when should we follow the JavaBeans specification? When property names should be inferred by accessors by tools that rely on this standard, then we might want to use it. For instance, Jackson will rely on the property xIndex being accessed through getxIndex and setxIndex methods unless we use annotations.

When should we avoid this standard? Per my recommendation: When the code should be read and understood by humans. Because to not use proper camel casing when naming methods is disinformative.

If I would have it my way, we would use normal naming conventions, ie getXIndex and setXIndex. But, given the state of things, the best solution I see is suggested by @vaxquis:

Name your field "indexX" or whatever else, your problem is solved... don't overcomplicate things - even if setxIndex is the correct way for Beans, having method named setxIndex increases the WTF factor of the code without giving you anything in return.

Any comments regarding the JavaBeans specification should, according the specification itself, be sent to [e-mail].

Answer 3

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

Answer 4

Should be:

getXIndex()
setXIndex(final int xIndex)

Answer 5

Eclipse ide automatically generates setters and getters as:

getxIndex()
setxIndex(int value)

Which is according to the java beans API specification.

Answer 6

You should use Introspector.decapitalize from package java.beans and you have no problem beacause it is compliant with java rules.