This seems like a mis-reading of the specification to me.

The full text of the section quoted is as follows:

When we use design patterns to infer a property or event name, we need to decide what rules
to follow for capitalizing the inferred name. If we extract the name from the middle of a normal
mixedCase style Java name then the name will, by default, begin with a capital letter.
Java programmers are accustomed to having normal identifiers start with lower case letters.
Vigorous reviewer input has convinced us that we should follow this same conventional rule
for property and event names.

Thus when we extract a property or event name from the middle of an existing Java name, we
normally convert the first character to lower case. 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. So for example,

• "FooBah" becomes "fooBah"
• "Z" becomes "z"
• "URL" becomes "URL"

So while I agree with the first two bullet points, the last one -- and the subject and intro of this entry -- are incorrect.  In accordance with the spec, 'aThing' does NOT have two upper-case letters at the beginning (only one), and so it would become getAThing().  It is not invalid, as this entry states.

In fact, use of a single lower-case letter is THE EXPECTED JAVA NOTATION for property names. This entry seems invalid in my opinion and should be revisited.

I like Java, but properties pretty much just suck - sun is like 10 years behind in this part of the spec, imo.

While you are correct that bullet #3 above is wrong (as demonstrated by the code below), I think you are over-reacting by stating that the entry is "completely invalid", it's not 100% correct, but it is a very common user error to see where someone posts to the list asking why their 'aString' property doesn't work. 99.999% of the time, it's because they coded the get/set methods incorrectly...which brings me to my original 'suck' comment.

Why can't Java do properties like .net? In .net, they are truly transparent properties (i.e., in code, I can say customer.name = "Some customer", not customer.setName("blah"), and if it is just a field, it gets set, but if it is defined as a property, it calls my setter for me. Seems like real encapsulation to me, not like Java. Interestingly - 10 years ago when I was writing FoxPro code...M$ did properties this way. Why has Sun still not figured this out? Lame.

Rant complete: I'll fix this entry.

public class BeanNameTest extends TestCase {
    public void testNaming() throws Exception {
        PropertyDescriptor[] propertyDescriptors;
        propertyDescriptors = Introspector.getBeanInfo(MyBean.class).getPropertyDescriptors();
        for(int i=0;i<propertyDescriptors.length;i++){
            System.out.println(propertyDescriptors[i].getName());
        }
    }

    private class MyBean{
        private String aString;
        private String string;
        private String AString;

        public String getaString() {
            return aString;
        }

        public void setaString(String aString) {
            this.aString = aString;
        }

        public String getString() {
            return string;
        }

        public void setString(String string) {
            this.string = string;
        }

        public String getAString() {
            return AString;
        }

        public void setAString(String AString) {
            this.AString = AString;
        }
    }
}

Thanks for revisiting and fixing the entry. I agree, in retrospect, that calling it "completely invalid" was an overstatement.

I must admit that aString -> getaString() is unintuitive – and that this nomenclature attribute of Java Beans sucks.

Personally, I think Java needs to be fixed. By using Attributes to dictate property naming, we can forgo the entire "convention" if we desire and do whatever we want. Of course, by default, such a solution would use the JavaBean specification's convention. This solution could easily be baked into the Introspector.

//example
public class MyBean {
    @BeanProperty(name="aString")
    public String getAString() { return "aString"; }

    @BeanProperty(name="foo")
    public String getScoobySnacks() { return "crazy"; }
}

myBean.aString --> aString
myBean.foo --> crazy

Of course, this has its downsides as you'd need to augment both the getter and setter, but I think the point is there has to be another way....