Win a copy of Java by Comparison (eBook) this week in the Java in General forum!

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
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

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.