Why is super.super illegal?

Well, from time to time I have the need to call super.super. I wonder why this is illegal. Doing some research on the Internet, the best answer I can come up with is, that it breaks encapsulation of the super.super class. Hmm, probably true in a clean world, but sometimes you really want to call back back the original functionality:

class A {
    protected void foo(){..}
}
class B extends A {
    protected void foo(){
        super.foo();
        doSomethingStupid();
    }
}
class C extends B {
    protected void foo(){
        super.super.foo(); // it is illegal to omit the stupid stuff of class B
        doSomethingUseful();
    }
}

Yes, B should not do stupid things. But why can't C undo what B does? In real software systems, that's exactly something that is somtimes needed. The answer that B should provide access to A.foo() if B thinks C would need it does not really satisfy me...

Come on, if java would really be concerned about encapsulation, all methods would default to final unless otherwise specified. Does everybody think about the fact that any non-final public or protected method can be overridden? No! We live with this accidental breakage of encapsulation and why is the small breakage of encapsulation that super.super does forbidden? Hey, a subclass can just override any non-final method without calling super at all, right? And C can call any method on B or A, but not super.super.foo()....

But maybe someone can give me an explanation that can convince me....

I hate ClassCastExceptions...

...because they don't tell me what the class of the "wrong" object was. No message, just empty. Where is the difficulty in telling me, what the actual type of the object was that caused the class cast exception? I rarely see them, but when I see them it's not informative enough -- I have to run the debugger but those rare class cast exceptions are often hard to reproduce...

Sun, please add runtime type of the casted object to the ClassCastExceptions message

How to setup some plugins to use java 1.5 in a java 1.4 workspace?

Most of the eclipse projects use and require java 1.4. Sometimes you want to create a new project to use java 1.5. If you simply install and select a java 1.5 in the Preferences->Java->Installed JREs, that would work, but cause potential problems. One problem is that you might accidentally use 1.5 features in 1.4 projects. A simple statement like:

string.replace("foo", "bar")

complies in this setup but will not run with a 1.4 jre, because

replace(CharSequence target, CharSequence replacement)

is new in 1.5.

The solution is to setup only the plugins that really need 1.5 to use 1.5 Eclipse has the concept of Execution Environments to specify which java JREs a plugin is compatible with.

1. set in the preferences an 1.4 jre as default and have an 1.5 installed:

2. In the project properties set the java compiler 1.5 (which is Compiler complience level 5.0 -- how I love the ever changing java version naming...):

3. Set the execution environment in the build path to J2SE-1.5:

4. In the plugin MANIFEST.MF, set the execution environment to J2SE-1.5 as well:

You could also directly add the following line to the MANIFEST.MF file

That's it :-)