class DD{
	static void doIt() {
		DD dd = new EE();
		dd.doIt();
		System.out.println("In DD");
	}
}
class EE extends DD {
	static void doIt() {
		System.out.println("In EE");
	}
	public static void main(String[] args) {
		DD.doIt();
	}
}

The concept to get from your prog is static methods are NOT OVERRIDDEN. Depending upon the type of the ref the method is linked. If the above code would have been change to

class DD{	
  static void doIt() {
  EE dd = new EE(); 
    dd.doIt();
    System.out.println("In DD");	
  }
}
, then the subclass class EE version of doIt() will be called and there id NO static overflow.   
regds
maha anna

Thanks for your profitable explanation of what's happening in the code Vishy submited.

About "Since the static methods CAN NOT be overridden":

Static method CAN be overriden, by static method.

It's even necessary sometimes. Consider this really minimalistic case involving a well known around example of static method:

class Base{
  void worthwhileReuseMethod{
    // 
  }
  public static void main(String a[]){    
    System.out.println("Hello from Base");
  }
}
class Derived extends Base{}
  public static void main(String a[]){ //  overriding Base
    // do SPECIFICS here;
    System.out.println("Hello from Derived");
  }
}

1/ Derived.class would unexpectedly print 'Hello from Base'
2/ We'd need plan B to make the specifics beeing called anyway

This said, I once more learned a lot from your explanation, about ref/static methods behavior I didn't suspected before.

Thanks for this.

JRoch

The code which you posted has some typo in it. Ignoring that, what is actually happening is , when you type 'java Derived' from command line, the JVM just loads the Derived and other needed classes and DOES NOT INSTANTIATE Derived class. It just calls the static method main(..) of the class which comes after 'java' at the command line. Compile the foll. code and see for yourself.
the output will be

Hello from Derived
Hello JRoch !I am from Base class //This is HIDING
Good-Bye! JRoch !I am from Derived class //This is OVERRIDING

regds
maha anna

class Base{
	public static void sayHello(){
			System.out.println("Hello JRoch !I am from Base class");
	}
	public  void sayGoodBye(){
			System.out.println("Good-Bye! JRoch !I am from Base class");
	}
	public static void main(String a[]){
			System.out.println("Hello from Base");
	}
}
class Derived extends Base{
	public  void sayGoodBye(){
		System.out.println("Good-Bye! JRoch !I am from Derived class");
	}
	public static void sayHello(){
		System.out.println("Hello JRoch !I am from Derived class");
	}
	public static void main(String a[]){
		System.out.println("Hello from Derived");
		Base d = new Derived();
		d.sayHello();
		d.sayGoodBye();
	}
}

Here's what R&H says about
Overloading and Overrinding, p.169 and p.170:

"Using the same method name with identical arguments
and return type is known as OVERRIDING".

Afterwhile on page 170:
"In a strict subclass of the class that defines the original method,
the method name can be reused with identical argument types and order
and with identical return type. This is OVERRIDING."

This is clear enough for me.

Sun JDK's compiler confirms this wording to be correct too: try in my example of overriding static method to make it more protected than it is in the Base class.

Or as an alternative, add to it "throws Exception" that does not exist in the Base class method. The compiler now complains that it cannot "override" anymore, due to the rules of overriding not beeing respected.

Also recent posts here or by Marcus site were concluding on the
fact that "only static methods can override static methods".

The fact that "hiding" better describes what really
happens under the hood when we syntaxically override,
that is, mask a static method in a source code by
another definition for the same method signature
is undeniable, but less largely known.

We most often see overloaded/overriden methods in Mocks
exams and books. Hidden methods is not this common..

I'll use it from now.

JRoch

PS: I've replaced "Good Bye JRoch" with "Good Sunday JRoch"
in your example with oObject instanciations

I think the real problem is that, while the JLS is very clear on the distinction, many of the people who use Java (especially the earliest users) are from C++ backgrounds, where overriding has a different definition. Naturally enough, this definition seems to be what RHE and various other people fall back on in many cases, whether they realize it or not. Apparently this includes the people who wrote those compiler error messages.