This week's book giveaway is in the NodeJS forum.
We're giving away four copies of Serverless Applications with Node.js and have Slobodan Stojanovic & Aleksandar Simovic on-line!
See this thread for details.
Win a copy of Serverless Applications with Node.js this week in the NodeJS forum!

Saad Benbouzid

+ Follow
since Jul 23, 2015
Saad likes ...
Chrome IntelliJ IDE Oracle
Lausanne, Switzerland
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Saad Benbouzid

Hi Jeanne,

I don't completely agree with your errata on page "" regarding the error Seb pointed for page 130, chapter III.

You wrote :

In table 3.4, the first should have a boolean return type. The second to last row should return E, not void.

but only the remove method should return E, not all method "from second to last row returning void should return E", because 2nd one (void add(int index, E element)) is actually correct in the book.

I would suggest more specifically :

In table 3.4, the 1st (add(E element)) should have a boolean return type. The 6th (remove(int index)) should return E, not void.

Roel De Nijs wrote:Because the property name is not limited to alphanumeric characters, you can have properties like color1, result2, and many more

color1 and result2 are actually of alphanumeric form Roel

But nevermind, I got my answer. Thanks again to you and Paul.

Paul Anilprem wrote:If you have a non-private method named getXxx, you have a property named xxx

That's it Paul, praise the lawd I finally got my answer ! My confusion was right here Paul, I see the light now.
Thank you all of you and sorry for my insistence.
I know Roel, and I agree.

But then what's the meaning of this : "followed by the rest of the property name".

What is the rest of the property name ?

Following your answer, all these four forms are correct answers, and alll these four forms follow the "4.5 statement", right ?

Then if I understand you correctly and if we agree so far, why is the "4.5 statement" not just saying :

The method name must have a prefix of set/get/is, followed by a letter in uppercase, [eventually] followed by an alphanumeric chain of characters.

instead of :

The method name must have a prefix of set/get/is, followed by the first letter of the property in uppercase, followed by the rest of the property name.

What is this "property name" mishmash, and why is this "property name" even mentioned if, as you state, field/instance-variable/property name has nothing to do with the accessor/mutator method name to be JavaBean compliant ?

@Paul: I wanted an example illustrating the assertion "[...], followed by the rest of the property name".
That is to say an example involving a property + an accessor (get) complying to the "4.5 statement" + an accessor (also starting with get) not complying to the "4.5 statement".

But as you told me there is no concrete and proper implementation in Java regarding "property", I asked what is the reason for this statement to remain as is in the book. At least the statement should say that it talks about "an abstract concept, which has no equivalent in Java, so just keep in mind that ... etc etc". And by "etc etc" I would expect, among others, the reasons why accessor and mutators can be written independently of the instance variable name returned. As you said, and as the exam expects it (making answer C correct).
Thank you Paul.

Too bad you didn't provide the concrete examples I asked for
However, for me the book must cover this statement with concrete examples, or straight delete this sentence. Suresh and I might not be the only ones wondering why C is still correct after this statement yet written in the official book.

(Page #206, table 4.5. : "The method name must have a prefix of set/get/is, followed by the first letter of the property in uppercase, followed by the rest of the property name".)

IMHO, this statement either needs to :
- provide concrete examples, including what part of the class exactly is the aforesaid property
- tell us why accessors written like answer C are also right, despite the "must" keyword and what is stated unambiguously

Can Jeanne please bring her insights on this and conclude on this thread ?

Paul Anilprem wrote:C is correct and the statement from the book is also correct. You seem to be confusing "property" with instance variable. If your method is getNumWings, then the bean is said to have a property named numWings. The fact that it does not have numWings variable and that it has numberWings variable is irrelevant.

BTW, option A is correct as well. It is valid for a getter method for a boolean property to start with the name is or get. Both are valid.

Hi Paul, thank you for your inputs.
Can you then please explain to Suresh and me what is, in this context, the difference between an instance variable and a property ?

I've read the glossary and some stackoverflows entries, but it's still unclear to me. Sometimes fields and properties are quoted interchangeably, and regarding the glossary a field is an instance variable :

I'm a bit confused since I've always thought property and instance variable mean the same (and I'm actually preparing for the certification to wipe away my numerous a priori :p).
Can you please provide two snippets, as examples describing both a property and an instance variable (within the same class) .


Roel De Nijs wrote:

Suresh Regmi wrote:if you look at the text book page number 206 table 4.5. It states, " The method name must have a prefix of set/get/is, followed by the first letter of the property in uppercase, followed by the rest of the property name". Then this saying is wrong.

And could you elaborate a little bit about the reason(s) why you think this statement is wrong. For me that's a true statement!

@Roel: When he said it's wrong, I think Suresh was talking about the answer C of question 9 (my original question). Because according to that statement, supported by the "must" word, for me answer C has no right to be true, since it's clearly not following the naming convention Suresh just quoted from the book.
Thank you for your answer Roel.

But nevertheless I find it strange, it's not what I've been taught about JavaBean's naming convention, that is to say :
- default or zero-argument constructor,
- implementation of the Serializable interface,
- public accessor and mutators methods.

I thought get() and set() methods have to follow the name of the corresponding properties. For example, your POJO strictly needs to follow this convention if it's involved into serialization and deserialization features, for example if you're using JAXB. If not reflection mechanisms won't work properly.

Serialization/Deserialization won't work for the "numberWings" property if you're exposing "getNumWings()" instead of "getNumberWings()". And it won't also work if you're not implementing simple pass-through getters, for instance "return new Integer(numberWings);" instead of "return numberWings;" regarding an "Integer numberWings" property.

I think that's also what's explained in the JavaBean spec :
See chapter 8.3 "Design Patterns for Properties".

I'm a bit lost then :/

Why is answer C correct ?
Shouldn't the method be named "public int getNumberWings() { return numberWings }" to be JavaBean compliant (camel-case form of the property name) ?

Why is answer D a correct answer ?

This code can't compile with solely the mentioned import : "import java.time.LocalDate;", because the import for the <Month> class is missing, as you can see :

So in my opinion as it is answer D is not correct, or answer D should be "java.time.LocalDate; import java.time.Month" instead of just "java.time.LocalDate".
I found this question not only tricky but straight unfair.
I've become very good at solving garbage collection questions, with my pen and my piece of paper next to me, but this question really annoyed me by the way it is written.

Why is answer D correct ? I think it can't be known since the garbage collector is unpredictable.
What if GC was called by the JVM just between line 9 and 10 ? Then you would have "g1" gc-collected after line 10 and answer D would be wrong since there would be no more grasshopper eligible for garbage-collection.

Why don't you keep this question as clear as for the exams 1 to 3 ? That is to say stating something like "Grasshopper from line 7 is first eligible for garbage-collection immediately after line 9", why this kind of unfair grammar innovation ?
The keyword here is "first", it dispels all ambiguities that come with the asynchronous and unpredictable GC mechanism.

I agree with you, but sometimes the questions state a fact without the use of "always" or "every" like it's the case for this question. And for those, some answers of the same kind of answer C (that is to say answers which sounds absolutely right) are marked as wrong answer because of an exception. And the official answer ("View Answer" popup) then says that it is false because of a particular exception (and even alerts you to stay focused, with expressions like "that's a tricky question !", "don't be fooled by the question !",...).

Once again, I agree with your answer on this one because I lengthily hesitated to tick it, but please notice that it's confusing for us as candidates to sometimes have to take into consideration every exceptions (special cases) and not to tick an answer which sounds right for 99% of the cases, and sometimes to have to ignore those particular cases and still tick the answer... :/

Following question points C as a good answer.
But don't you think static methods declared in interfaces also belong to the questions since it's written 'interface methods' (implying and including static methods, the new interface feature from Java 8) ?
And I thought static methods declared in interfaces can't be overriden, not even in an abstract class, am I false ?

Thank you for your answer.