Tommaso Nuccio

Ranch Hand
+ Follow
since Dec 11, 2006
Merit badge: grant badges
For More
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 Tommaso Nuccio

Hi all,

I have a table with tableItems and each tableItem registers two Listeners:

Further I have a handleEvent(), like this:

The MouseHover works and you get a Tooltip for each entry. But then the tooltip stays forever, because the MouseExit doesn't fire and the tooltip is not removed.

My question is, why does the MouseMove doesn't work?
Maybe the tableitems cannot register a MouseMove? When so, where can I find a list with a component <-> Listener relation?

Many thanks in advance.

16 years ago

you must be a poor idiot...

Hi Richard,

I think you must specify the lefthand operator more specific:
--> if ( f[0] instanceof Foo ) ;
--> if ( f instanceof Object) System.out.println("Object");

Good luck.

Originally posted by John Mathew:
37. Which of the following statements about Java's garbage collection are true?

a) The garbage collector can be invoked explicitly using a Runtime object.
b) The finalize method is always called before an object is garbage collected.
c) Any class that includes a finalize method should invoke its superclass' finalize method.
d) Garbage collection behavior is very predictable.

to a)
-> No, you can only suggest JVM to run the gc.

to b)
-> No, it is not guaranteed that the finalize() method is called. (K&B, SCJP 5, page 253)

to c)
-> I am not sure here, but I think this is correct, as finalize() is declared in the objet() class. Thinking twice it must be, because everything up the inheritance tree must be cleaned. It is vice versa of the constructor logic.

to d)
-> definitely not. You never know when it is going to run and what it going to do, besides cololecting garbage.

Good luck.

what is the actual question?

As Vassili said
The "tree" object is of type "Pine".
Pine extends Tree, thus Pine IS-A Pine itself and Pine IS-A Tree.
Pine IS-NOT-AN OAK, that's why it prints "Oops" instead of "Oak".

Good luck.

it prints also 100 endlessly on my computer.

I see it the same way.

I hate this code snippets that are not formatted.
The catch has a body with a System.out.

Omer is of course correct.


Originally posted by Tina Tibrewal:
IOException is a subclass of Exception.

Which one is checked?

Good luck.

what is the difference between
- Exception
- IOException

Good luck.
From looking at it, this will end in an endless loop printing 100.
The run method never leaves the while(true)-loop

Good luck.

if you debug it using breakpoints, the compiler will tell/show you that during the call of the method call() in the superclass constructor the this object is of type Q05.

Good luck.

well the example is not too elaborated, because Mr Scheduler can have more than one key, one per instance, but you get the idea.

Good luck.
I'd say it is false.

Objects become eligible for GC only when nothing points TO them, i.e. the references to them have been set to null.
But if an object in initialized, then put into an array and then the object is set to null, the array still uses it/references to it.

What do you think?
Hi m(are you the one from James Bond ),

I give you two explanations:
1 - only one lock per object.
2 - "synchronized" tells a thread, "You can only enter, if you have the lock on the object!"

Can another thread get the lock, when trying to access another synchronzed method?

Imagine a house with 5 rooms, 3 of them have a door which can be locked with a key and are per default locked. The housekeeper, Mr Scheduler, has only one key and he is the only one to give it to someone.
Now we have three guys in the house and all really need to go for a pee
The bathroom is one of these three locked rooms. So Mr Scheduler decides to give the key to the guy, who currently has the highest priority. That is Peter, because he has been drinking water the whole day and really needs to ...
Peter gets the key, enters the bathroom and locks the door.
The second guy is hungry and wants to enter the kitchen, that is also locked. But the key is with Peter in the bathroom!
How can he enter the kitchen?

Good luck.

there is only one lock per object. This makes sense, because if a Thread picks up the lock, no other thread can access the object. And that's what it is all about.

A thread can get more than one lock, i.e. two locks on two different objects. It enters a synchronized method and gets the lock on an object and within this method it maybe access another synchronized method of a different objects and gets that lock also.

If you have a synchronized block in a static method, the lock is for the whole class, because static methods are class methods, whereas non-static methods are specific to an instance of a class.

Good luck.