Pedro Ivo Dantas

Greenhorn
+ Follow
since Sep 03, 2004
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 Pedro Ivo Dantas

Weel, just to make this topic clear: when using the instanceof operator, the left operand can be any java object, while the right hand can be any java class. It will return true if the object is a instance of the class, or any of it subclasses. This relation is also valid for interfaces.
Every constructor needs to have a call to super(), but if you forget it the compiler will put the call there for you. Remember however that if you do put it in your constructor, it must be it's first statement. The call to this() is not necessary, only if you want to call a overloaded contructor.
Hum, I think you are not right Mike. You have to consider the hierarchy of the classes of the object being compared. Variable o is declared as Object, but it holds a reference to a ICheck instance. ICheck extends Check, which extends Object, just like any other java class. Therefore it is a instance of any of these classes, and will passa the instanceof comparation for any of these.
If you compare any object with the class Object (xxx instanceof Object), the comparation will be true, because every object extends Object. But remember, the object in the left MUST BE of the same class or a subclass of the class on the right.
Hope I've made myself clear.
[]s
Pedro Ivo
It�s important to note that the equals method in the Object class does the same that the == operator do. It checks if the variables reference the same object in the heap. So unless you override the equals methods in your class to do something smarter, for example comparing the instance variables of the objects, a call to equals() is identical to using ==.
It depends on the type of the variable i. If it is a int, as I suppose was your intention, then the resulting value will be -1 (11111...1111). If it is a long, then the result will be 0.
Thaks fot the reply Mike!
Guys (and girls ;-))

I am reading the Bathy and Berts book and have a doubt about the case construct. Yhe book says "The case argument has to be resolved at compile time, so that means you can use only a constant or final variable that is assigned a literal value." It also has an example:

Ok, my doubt is: why do we get a compiler error when using variable b? I mean, it's declared final, and is assigned a value before the case test. So, in my opinion, it can be considered a constant, but Kathy (and the compiler, by the way) tell me otherwise. Could someone please explain this to me?
Thanks!
Pedro Ivo Dantas
The key point to this question is the call to System.gc(). When you call this method, you are asking for the JVM to run Garbage Collector. It will search for objects eligible for garbaging, and will call the finalize() method once in these objects. Note, however, that you can only suggest that the garbage collector should run, the JVM can completely ignore you, or can do just part of the work, there is no way for you to know.
So back to the question, waht happens is that after the call to m1(), we will have A1A2A3A4 printed in the console, as you would have expected, and three objets eligible for garbage colleting, pointed by a1, a2 and a3 (note that a0 is not an object, just a reference to one). So the Garbage Collector will finalize none, any or all of these objects, calling its finalize()'s methods, which prints their names. Therefore, the answers a,c,d,e are all possible to happen. Running the example in my computer I always got answer d, A1A2A3A1A1A2A3, but this doesn't mean that the others are not possible.
Hope this can be helpfull! Cheers!
Interesting points Marc. It seems you solved the puzzle. I had no idea arrays behaved this way.
>As per Sierra & Bates's book (pg 70) "if a subclass inherits a member, it's >exactly as if the subclass actually declared the member itself. In other >words, if a subclass inherits a member, the subclass has the member."
That�s what inheritance is all about, but that�s not the case here. It�s a matter of scope. When you acess a member, the JVM always searchs first in the current class, if the member is not found there it searches in the super class and keeps going. It *never* searches "down" the hierarchy.
So, since the method is being called in the Car class, it�ll try to acess the variable in the Car class, not in the BMW subclass. If you uncomment the method declaration like Tom said things would work differently.