• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
I Danilov
Greenhorn
Posts: 8
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Greenhorn
    Posts: 8
    3
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    author & internet detective
    Marshal
    Posts: 35279
    384
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    author & internet detective
    Marshal
    Posts: 35279
    384
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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)Output: -spaß-spaß-SPASS- (so one extra letter in upper case)
     
    Ellen Bee
    Greenhorn
    Posts: 6
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Posts: 10662
    144
    AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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".
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic