javabeans naming conventions (Java OCA 8 Programmer I Study Guide)

[I Danilov]

I mistakenly first posted that to another book's errata topic. Doesn't seem there's a topic for OCA 8 study guide, so I make a new one.

p206 table 4.5

Getter methods begin with is if the property is a boolean

p206 example explanation

Line 14 doesn't follow the JavaBeans naming conventions. Since playing is a boolean, the getter must begin with is.

p344 answer for review question #9

Option A is incorrect because the property is of type boolean and getters must begin with is for booleans.

JavaBeans specification 1.01 final release, section 8.3.2:

In addition, for boolean properties, we allow a getter method to match the pattern:

public boolean is<PropertyName>();

This “is<PropertyName>” method may be provided instead of a “get<PropertyName>” method, or it may be provided in addition to a “get<PropertyName>” method.
In either case, if the “is<PropertyName>” method is present for a boolean property then we will use the “is<PropertyName>” method to read the property value.

As for real world examples, JSP EL accepts getBooleanProperty() as a valid property getter.

[Jeanne Boyarsky]

We are posting the confirmed errata here. In the book the JavaBeans discussion is just meant to be about common conventions. While I don't consider this an errata, I've made a note to make this clearer if we do another edition of the book. Thanks!

[Roel De Nijs]

Hi, I Danilov,

First of all, a warm welcome to CodeRanch!

I Danilov wrote:I mistakenly first posted that to another book's errata topic. Doesn't seem there's a topic for OCA 8 study guide, so I make a new one.

No problem! As per your request I removed that particular post.

I Danilov wrote:p206 table 4.5

Getter methods begin with is if the property is a boolean

It seems the JavaBeans Standards aren't a part anymore in the K&B7 study guide. So I had a look in my K&B6 study guide. There's a clear distinction between a non-boolean property and a boolean property:

K&B6 wrote:

If the property is not a boolean, the getter method's prefix must be get. For example, getSize()is a valid JavaBeans getter name for a property named "size."

If the property is a boolean, the getter method's prefix is either get or is. For example, getStopped() or isStopped() are both valid JavaBeans names for a boolean property.

I Danilov wrote:JavaBeans specification 1.01 final release, section 8.3.2:

For those interested in this specification, you can download the PDF document here.

Kind regards,
Roel

[I Danilov]

Jeanne Boyarsky wrote:We are posting the confirmed errata here.

Yes, I read that page. It wouldn't hurt to also specify how to report possible mistakes. I hope the way I chose is acceptable.

Jeanne Boyarsky wrote:While I don't consider this an errata, I've made a note to make this clearer if we do another edition of the book.

Now that I read my original post, I should have stated the relation to specs clearer, sorry that it wasn't clear:

Information about boolean properties in the book contradicts the specification. The table says boolean property accessor cannot start with 'get'. The text says boolean property accessor cannot start with 'get'. Most confusingly, one of the review questions has a boolean getProperty() accessor, and that answer is explicitly marked incorrect. I think that's quite erroneous.

I just happened to have some experience with JSP, so that made me running to google, to see if any new javabeans spec did come out (nope). Now that I recollect why I ever read this spec in the first place - there's also that part (section 8.8 of javabeans spec):

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”

My getAProperty() accessor for aProperty was doomed from birth.

Oracle certification study guides are generally considered a good material to obtain a solid knowledge of Java language fundamentals, but some parts in this one seem like they may leave the inexperienced reader with not-quite-right knowledge

Off-topic:
Certainly not an errata, but java.lang.String methods equalsIgnoreCase(), toUpperCase(), toLowerCase() are well known in some non-english speaking countries for their inconsistent behavior. equalsIgnoreCase() is implemented on assumption that converting case does not change string length (which is not true); toUpperCase() and toLowerCase() may return different results depending on locale, and yes they may change string length. There's java.text.Collator class for comparing strings in strange languages. Maybe you could consider adding this as a note for another edition. Thanks.

Roel De Nijs wrote:For those interested in this specification, you can download the PDF document here.

Thank you sir, it was thoughtless of me to forget a link.

[Roel De Nijs]

I Danilov wrote:

Jeanne Boyarsky wrote:We are posting the confirmed errata here.

Yes, I read that page. It wouldn't hurt to also specify how to report possible mistakes. I hope the way I chose is acceptable.

Sure! Jeanne visits this forum very regularly, so if you use a meaningful subject, she'll definitely notice the possible errata items. And otherwise I'll draw her attention to your topic

I Danilov wrote:Certainly not an errata, but java.lang.String methods equalsIgnoreCase(), toUpperCase(), toLowerCase() are well known in some non-english speaking countries for their inconsistent behavior. equalsIgnoreCase() is implemented on assumption that converting case does not change string length (which is not true); toUpperCase() and toLowerCase() may return different results depending on locale, and yes they may change string length. There's java.text.Collator class for comparing strings in strange languages. Maybe you could consider adding this as a note for another edition. Thanks.

Don't forget you are using a certification study guide. Its sole and only purpose is to prepare you for the exam. java.text.Collator is not on the exam, so it's normal this class isn't mentioned in the study guide as well. But it would indeed a nice "on the job" recommendation.

[Jeanne Boyarsky]

I Danilov wrote: Yes, I read that page. It wouldn't hurt to also specify how to report possible mistakes. I hope the way I chose is acceptable.

Yes. This is my preferred way of people reporting errors. In this forum, one per thread. That lets us hold discussion about any as needed and make it easier for me to find them/keep track.

I Danilov wrote:Now that I read my original post, I should have stated the relation to specs clearer, sorry that it wasn't clear:

With the added problem of me being ready to go on vacation and not actually checking what I wrote in the book and just responding to a small fraction of your post. You are completely correct. I've updated the errata and given you two cows. (Thank you for challenging me). The good news is that JavaBeans aren't actually on the exam *as of right now*. Oracle likes to add/remove topics over time. Since JavaBeans aren't a complicated topic*, I figured it wouldn't overwhelm readers to include it.

* says the person who managed to botch it up!

[Jeanne Boyarsky]

I Danilov wrote:Off-topic:
Certainly not an errata, but java.lang.String methods equalsIgnoreCase(), toUpperCase(), toLowerCase() are well known in some non-english speaking countries for their inconsistent behavior. equalsIgnoreCase() is implemented on assumption that converting case does not change string length (which is not true); toUpperCase() and toLowerCase() may return different results depending on locale, and yes they may change string length. There's java.text.Collator class for comparing strings in strange languages. Maybe you could consider adding this as a note for another edition. Thanks.

I have an excellent reason that isn't in the OCA book. Internationalization and localization are covered on the OCP, not the OCA.

They aren't on the exam in the OCP either. (only the basics of I18N/L10N are covered.) My reason for not including them there (already wrote that chapter) is "less good." Scott and I both live in the United States and work on primarily English websites. So not experts in that space. I personally had no idea that changing the case could change the string length. Which is certainly interesting to know. We can only stick in so many side notes about things that aren't on the exam and try to stick to the most common ones. Plus it's probably common knowledge in whatever language has that use case. (Do you know an example of a language that works like that?)

[Roel De Nijs]

Jeanne Boyarsky wrote:Scott and I both live in the United States and work on primarily English websites. So not experts in that space. I personally had no idea that changing the case could change the string length. Which is certainly interesting to know. We can only stick in so many side notes about things that aren't on the exam and try to stick to the most common ones. Plus it's probably common knowledge in whatever language has that use case. (Do you know an example of a language that works like that?)

Being from Belgium with 3 official languages (Dutch, French and German) I have a little experience on this topic (definitely not an expert).

This example immediately popped up in my head. It's about the German eszett (or sharp S)

String s = "spaß"; // fun in German (and fun it definitely is :))
System.out.printf("-%s-%s-%s-", s, s.toLowerCase(), s.toUpperCase());

Output: -spaß-spaß-SPASS- (so one extra letter in upper case)

[Ellen Bee]

Jeanne Boyarsky wrote:We are posting the confirmed errata here. In the book the JavaBeans discussion is just meant to be about common conventions. While I don't consider this an errata, I've made a note to make this clearer if we do another edition of the book. Thanks!

If I understand correctly from another thread on this topic: The property isn't necessary the same as the instance variable/field. Therefore I think the first rule in table 4.5 is incorrect in saying "Properties are private". I think a main cause of the confusion is that rule with the example of the instance variable.

[Roel De Nijs]

Ellen Bee wrote:The property isn't necessary the same as the instance variable/field.

That's true indeed! The property name of a JavaBean depends on the getter and setter methods, not on the instance variable (field).

Ellen Bee wrote:Therefore I think the first rule in table 4.5 is incorrect in saying "Properties are private". I think a main cause of the confusion is that rule with the example of the instance variable.

I agree! To avoid confusion it's probably better to change the first rule in table 4.5 to "Instance variables (fields) are private".