Rick Zhong

Greenhorn
+ Follow
since Apr 13, 2001
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 Rick Zhong

these two classes has no relationship whatsoEver, so there no 'overriding' such thing, besides, these two method can not pass compiler check given the two classes inherited each other for they have different return type!
am i right, correct me if i am wrong, please
Rick
Hi, marlon,
the reason why 0 got printed instead of 4 is for :
1)Dynamic binding of overriding method during runtime, which is to follow object B in this case
2)int i= 0 at the time while print() method invoked, so 0 got printed!
hope help
Rick

hope helpful
Rick
[This message has been edited by Rick Zhong (edited April 13, 2001).]
what happens here: i think
i=i++;
JVM does following in background
1st step: int temp=i;
2nd step: i=i+1;
3rd step: i=temp;
let me know if i am wrong
Rick
[This message has been edited by Rick Zhong (edited April 13, 2001).]
hi, Lam,
runtime error here is an Undowncastable problem, here is the term of 'overloading' defined by jls:


If two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but different signatures, then the method name is said to be overloaded. This fact causes no difficulty and never of itself results in a compile-time error. There is no required relationship between the return types or between the throws clauses of two methods with the same name but different signatures.


Rick


call sleep() (inside run() for example) equals Thread.sleep() equals this.sleep(); i guess, JVM will take the context of instance of 'this' as arguments which is specific to 'this' instance in manipulating 'this' thread only! a guess ONLY doing this way can avoid doing GENERAL things which might effect other thread as a static method -native method actually, we will no way in knowing what is going on inside indeed, don't u think?
any comments, guys?
Rick



[This message has been edited by Rick Zhong (edited April 13, 2001).]
call sleep() (inside run() for example) equals Thread.sleep() equals this.sleep(); i guess, JVM will take the context of instance of 'this' as arguments which is specific to 'this' instance in manipulating 'this' thread only! a guess ONLY doing this way can avoid doing GENERAL things which might effect other thread as a static method -native method actually, we will no way in knowing what is going on inside indeed, don't u think?rolleyes:
any comments, guys?
Rick
add(Component,Object obj) enlarge the function of add(String,Component), for String is an Object too
Rick
Hi nachiket,
the result coming out like these is because it has nothing to do with overriding or dynamic binding, the method eat() invoked according and ONLY according to the reference type!
however, i have a ques about overloading term itself, can we say the three eat() are OVERLOADING methods even though they are not defined within the same class!?
anyone can clarity it?
Rick

Hi, nachiket,
try this: (byte)(x<<1) ,then you will know what is going on here.
hope this help
Rick