Misunderstanding on JavaBeans naming convention for methods on OCA

Question

We are currently having same tests for the OCA certificate and today we run into a minor an issue. I'll try to keep is short:

Which are methods using JavaBeans naming conventions for accessors and mutators?

(Choose all that apply)
A. public boolean getCanSwim() { return canSwim;}
B. public boolean canSwim() { return numberWings;}
C. public int getNumWings() { return numberWings;}
D. public int numWings() { return numberWings;}
E. public void setCanSwim(boolean b) { canSwim = b;}

The answers (as specified by the OCA SE 8) : C and E

Our discussion was on the point C:

public int getNumWings() { return numberWings;}

The point of my colleagues was that it is wrong due to the rule mentioned below. The method accessor must've been getNumberWings so the point C was wrong. I have attached the table of rules from the OCA, where it think the rule 5 is wrong. PHOTO of Rules for JavaBeans naming convention on OCA SE 8 page 206

From my knowledge the name of the method doesn't have to respect the the property. What are your thoughts on this?

---

OCA Oracle Certified Associate Java SE 8 Programmer I Study Guide Exam 1Z0-808

I tried to find a proper answer also on:

JavaBeans conventions from oracle: http://download.oracle.com/otn-pub/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/beans.101.pdf?AuthParam=1484818426_7e07f5a35c14ebfbadb2c68798198d7e

JavaBeans Conventions (Java in a Nutshell)

Answer 1

Your colleague is (I think) arguing that

public int getNumWings() { return numberWings;}

violates the JavaBean because the field name and the property name are different.

That is not supported by the spec. The Java beans conventions (as codified here) state:

6.2.2. Properties

A bean defines a property p of type T if it has accessor methods that follow these patterns (if T is boolean, a special form of getter method is allowed):

Getter

    public T getP()

Boolean getter

    public boolean isP()

Setter

    public void setP(T)

Exceptions

Property accessor methods can throw any type of checked or unchecked exceptions

Note that it does not say anything about the name of the (typically) private field that holds the value of the property. Indeed, the field may not even exist ... if the property value can be represented some other way.