Rein de Boer

Greenhorn
+ Follow
since Jul 12, 2009
Merit badge: grant badges
For More
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 Rein de Boer

Sharmila Punde wrote:Hi All,


The output is - false

Why this time output is false? Why second excerpt do not unbox the returned Integer?
Regards



To make matters complicated, on my JVM, this does print 'true'
Looking in the source the function with parameter string is implemented like this:


Latest JVM 6, windows
as far as the compiler is concerned, test_one does not implement face (only test40), so cannot be assigned to face.
To add to the previous post, iFour is a reference variable (to object type Integer), not a value type. So therefore not usable in a case.
you're right.
to make synchronization work, you would have to make the method static and then synchronize, or create a specific synchronization block in the function and lock on the var object (which is also static).
you're right, that var is always 0.
so it has got no impact on the outcome in fact.

the issue is 2 threads, running together, with no synchronization, each outputting the counter values in order. so the output of the values is indetermined because of that, because you have no guarantee when and for how long each thread runs.
if gun() was synchronized, then there would be a predefined order.
because var is static, all the different instances access the same variable, so the explanation is right.

vijayakrishna Mikkilineni wrote:
Does Auto boxing apply to constructor args also or is it to only method args?



I would say that a constructor is like any method (with respect to the arguments).
oh actually i see the issue now...
the value to print (i) might be changed by a different thread right before it is printed.... So i agree with Henry Wong :-)
yeah, but the x value is function local, so each run() has to go through the whole for loop (no changing of x from other thread possible) before it reaches the print statement...
so i would agree that values <10 will not occur...

Samrat Som wrote:The correct answer is abc123. As the synchronized method are class level lock and the numbers.start () thread would only get access to the synchronized method say(). only after letters.start() thread has completed its execution. This is the final answer , as I suppose.



I disagree with that.
The say() has indeed a class level lock, but only the individual calls to it are synchronized, not the sequential calls. So the calls of the individual threads can be mixed.
The only guarantee you have is that the calls in each of the run() functions are in the order. so b always after a, c always after b, etc...

The answer is, as stated in the first post: C/D/F/G
The run methods are not synchronized, only the 'say' method.
So the only restriction is that, the 'a,b and c' should be in the correct order, and the '1, 2 and 3' should be in correct order.
That is only not the case with C and D.
And of course no compile/runtime erros will occur.
Shouldn't the split string in the last 2 examples of the openingspost also be 'aa' or 'a{2}', to match the number of found strings given?
But only if you use literals to assign to the wrapper objects (like true/false, 0, 1).
if you would use

then the output would be 'falsetrue', since 2 different objects are still involved.

You can see at as if the compiler replaces a small set of literals with a call to the static .valueOf method which uses cached values if possible.