Graciela Zaffarana

Greenhorn
+ Follow
since Jan 09, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Graciela Zaffarana

Hello Vishwanath ...

I greatly appreciate your pointers and references. I will follow up on them. ( I was almost losing it yesterday --- not even trusting the "for-loop"! )

Best regards,

G.Z.
Yes, indeed! I can see now how synchronized(this) works just fine using the runnable interface version as opposed to the inheritance version. Gosh! Thank you so much!!!

I can now see how both versions tackle the runnable target; to me, it is easier to follow the "interface version" But, no doubt one needs to fully understand both.

Thank you very much!

Graciela
Please, see code below.

Locking on Integer object -- either first or redlight -- renders the desired result: each thread completes the 12 iterations before the next thread comes around.

On purpose, I avoided using a for-loop. I am trying to understand what "this" in synchronized (this) means. I do not understand why if I replace either object --- first or redlight --- with "this" and still keep the curly braces arond the same lines of code, I no longer get the desired result. What does "this" mean? I cannot find a case where I can use synchronize (this) effectively.

Thank you.

Yes, yes; I am afraid that I realized after I hit the submit button. Was surprised that none was jumping the gun. My apologies.
And, yes, yes. Rule of thumb: constructors can be overloaded but not overriden. Well... better now than at exam time!

Thank-you,

GZPortland -- very greenhorn
Hi there ...

I am in the middle of inner classes myself; I took a look at the code submitted; with some minor changes as shown below, the code compiled.

Best,

GZPortland


My! Talking about setting the bar high for the rest of us... Congratulations!!!
8 years ago
Congratulations, indeed! Quite a feat!

And, thank you for sharing your test experience as well as pointers on how to prepare for the test.

Cheers!
8 years ago
Sorry, I posted the code with my changes. Here is the original as showing on the Self Test question:

Hey! but at least in question 9 of Chapter 1 "myGold" is boxed; in question 15 of Chapter 2 it is not. Okay, okay ... I will hang in there one chapter longer to be enlightened.

Here is the code: ( I hope that I am posting it right -- with line numbers --- when I click the <submit > ; otherwise, tell me how, I will know better next time around. Cheers!

Congratulations! And thank you for the pointers!

What a feeling of relief, huh?

Cheers.
8 years ago
Study Guide 6 -- Chapter2 Self Test Question 15 on page 181.

Hello Fellas ...

(1) It is clear that the code on question 15 compiles; I verified that. But, does int 7 in line 12 --- "sifter(7)" get boxed by the compiler behind the scenes? Really? Do I have to read more through the book to get an answer on how the compiler does it, or can you tell me? Without having to declare it as: new Integer(7)? Please, comment. ( It goes without saying that I had chosen Compilation fails because I thought that 7 was not an Object but primitive data. )


(2) Also, It occurred to me to comment out the version of method sifter that expects an Object to see if array "aa" got routed to version of sifter with argument equal to A[]... a2, and indeed it did! So, is there more than one answer to this question? or should we consider the comment " In general, overloaded var-args methods are chosen last." as the law of the land? ---

NOTE: In the process of recompiling the code after commenting out line 18 sifter(Object o) , I had to also comment out line 12 sifter(7) --- Interestingly enough, the compiler error sort of directed me to think that it views 7 (like I do) as a primitive integer and not as an object of type Integer. Compiler error message is somewhat misleading in my view.

Greatly appreciate your input.

Best,

Wanna be a "Java compiler thinking machine"
Hello Neha ...

Okay; we are on the same page now. Thank you so much for taking the time to follow through my question. I greatly appreciate your input. Best regards, GZ!
Thank you Neha ...

I apologize; we keep cris-crossing messages ...

Beef is the class that resides in the same package as Apple. Apple is the derived class. Fruit is the superclass that resides in a different package from Apple and Beef.

In the class Beef, line 43, you can see that via an instance of Apple, the protected superclass member fruitbasked can be accessed; in this case it is a getter but it could have been a setter as well. The book speaks of (D), (I) or (R) accesses on page 37 --- Study Guide 6.

The code that I submitted suggests to me that one can indeed access by reference a protected member in a Superclass from a class that resides in the same package as a derived class, but different fromt the superclass.

Thank you for your input and patience.
Okay. I now see what is going on. Thank you for your input. Best regards.