Rafael Souza

I think Oliver's resolution is the correct one.

Some content firts:

A) When an object is being created, its attributes need to be initialized.
B) Always one a new instance is created all the supertypes constructors are called.

Now the problem:

1. The attribute k is marked to be initialized with a new ram object.
2. So, to create a Test object we need to create a ram object to initialize k variable.
3. And to create a ram object we need to call Test's constructor.

So, we have this situation: to call Test's constructor we need to call ram's constructor and vice-versa. Those steps are repeated over and over until we reach a java.lang.StackOverflowError.

Edit: when I said in item B that all the supertypes constructors are called of course I meant that one constructor of each supertype is called.
[ July 05, 2007: Message edited by: Rafael Souza ]

Let's see...

First, the idea of covariant data type on return exists only when you are overriding methods. If you have two methods with different types of arguments, the two methods are different ones... as you said, its an overloading. So, it doesnt matter if String extends Object... they are not covariant in this context.

Now what do we have:

SuperClass: Object get (Object){return "super";}
SubClass: String get (String){return "sub";}

SuperClass superC;
SubClass subC;

When we have overriding, through polimorfism, at runtime the code that will run is that of the type of the actual object. But as we have an overloading, at runtime the code that will run is that of the type of the variable. So, as the type of the variable is SuperClass, what runs is the version of SuperClass get() method.

Now let's make some adjustments at your code to make things more complicated:

if the type of the argument in subclass was Object, then we would have overriding and you try to run the same code with new adjustments, you may note the same results would be:

superclass version
subclass version
[ July 04, 2007: Message edited by: Rafael Souza ]

Actually when you call Calendar.getInstance(); what happens inside getInstance is that an object of a concrete class is created. Normally it�s an instance of java.util.GregorianCalendar, which is concrete.

Think like this: among other stuff, the method Calendar.getInstance() does something like return new GregorianCalendar(); So it doesn't try to instantiate Calendar (which is abstract), but GregorianCalendar (which is concrete).

Try to run the code that follows and you will notice that the result is: java.util.GregorianCalendar

import java.util.Calendar; public class Teste { public static void main(String[] args) { Calendar c = Calendar.getInstance(); System.out.println(c.getClass().getName()); } }

when i replied before you hadn't edited yet.

ok... what is happening here... when you write method() in Derived class you are actually creating a new method... you are not overriding that one in Base class... you can check this by trying to change the return type or even declaring new checked exceptions in class Derived (things that wouldn't be possible if you were overriding Base's method().

method() is visible only in Base class. It runs through a variable of Base type. When method() is called, it prints the name of the classe of the object is currently running (which is an instance of Derived).

All in all, there�s no need to be surprised when this code compiles and runs successfully!

(Hi, I�ve just signed into this forum. Welcome me )