Gaurav Arora

Tim Holloway wrote:
..
In older JVMs there were performance advantages to declaring a class final. They supposedly no longer apply, but some classes are final for other reasons.

I wonder if thats actually true. I'd appreciate it if you could present an article or something. I have read that very statement on a few different sites but have never found anyone who is able to cite his sources.

A negative value means that if a list containing a number of anotherObject objects is sorted then anotherObject will appear before thisObject in that list.

By default spring managed beans aren't supposed to hold state because their default scope is singleton. If you want your spring managed bean to hold state, you must change its scope.

I would suggest against having your business layer store state.

Originally posted by Ashok Pradhan:
I want to know when we apply Thread.yield() on a running thread ,what actually happen.it goes to runnable state and come back again to running state or goes to runnable and never come back or nothing happens.please clarify my confusion.

Using yield() causes a thread to go into runnable state and allows other threads to execute while pausing the current thread. However, this is in no way guaranteed since the scheduling is OS dependent and the scheduler may decide to give time to this very thread again. It is therefore recommended that if you _absolutely_ need a thread to go out of execution, you should use sleep() instead of yield().

As to the second point, the thread will come back again for execution if you use yield().

If the two threads use the same JVM then yeah, using a map would work. But if they don't, it won't.

Am I correct to assume that the locking is only required when the database access is provided over a network? And no locking is required for a local database?

Originally posted by Uttara Rishi:
Hi Ranchers,
The above code compiles while the following one doesnt.
Integer as = 303; long lo=303l; System.out.println(as==lo); // Line 1
I am getting a compiler error on line 1. Can somebody please explain?

Thanks in advance.

Uttara Rishi.

Compiles for me, check your compiler compliance level and try to compile manually using the -source switch.

0x1 only works when the jvm autoboxes the value.

Short s = 0x1;
will work.

I can only guess that the JVM internally parses the value to a 'short' and then calls the Short(short value) constructor.

Other than that, i'm sure you can find out the default constructors from the docs. Docs

That was an incorrect statement by me kesava, ignore it and thanks for correcting me.

Originally posted by Rahul Singhai:
Guys,
What about 5. private transient..
it also seems to be a possible correct answer.

(Choose the shortest possible answer.)

You are not allowed to remove elements from an Enumeration type in effect giving you a "view" only.

You can remove elements from an Iterator type thereby giving you "view & modify" behaviour.

This is from the javadocs :

NOTE: The functionality of this interface is duplicated by the Iterator interface. In addition, Iterator adds an optional remove operation, and has shorter method names. New implementations should consider using Iterator in preference to Enumeration.

The compiler doesn't know at compile time if the interface Animal has any sub classes or not so at compile time it assumes if you say, a.eat(); you're calling the eat method of the Animal class.

But at runtime, it's a different story. The reference variable is of the type Animal but the object is of the type Dog so the eat() method of the Dog class is executed.

Ummm ... what? What chapter or exam objective are you talking about?

Case 2 is not executed at all. Here's the flow :

case 2: i != 2 so skip;
case 4: i != 4 so skip;
default: if no other case has been accepted till now, accept this one. so j = j + 2; j = 2;
case 0: i == 0; j = j + 4; j = j + 2; j = 6;

The default case is always executed if no other case before it has been irrespective of whether cases after it will be executed or not.

Hope that explains it.
[ March 05, 2008: Message edited by: Gaurav Arora ]

Apparently it is valid (since it compiles) and the value is y + 1.

The right side is evaluated first so y becomes one because of (y=1) and then the old value of y is added to that 1 to output y + 1.

Originally posted by Nabila Mohammad:
Can some tell me why c2 is not null.
Isnt cb pointing to c2 on the heap.So if cb is null wouldnt that mean, c2 is null as well.
Can some one make this more clear.

The actual object, c2 is not null because the method go only holds a reference to c2 and not the actual object. That reference is null, not the object.