- Joined
- May 7, 2009
- Messages
- 1
- Reaction score
- 0
There have been a few posts here asking for and denigrating the construction super.super.method(). After ten years of programming in Java I have run into a situation where it would have been useful:
I am making a subclass of javax.swing.tree.TreePath. My approach is completely different so I am using none of the fields of the original. And anyway, TreePath.lastPathComponent is private. Now TreePath.hashCode() relies on lastPathComponent, so calling hashCode() on one of my subclass objects fails. What I would like to do is override hashCode with a version that retrns the default Object.hashCode() value. That is, I really do want super.super, as in:
public int hashCode() {
return super.super.hashCode();
}
But super.super.xxx, alas, is illegal. Note that nested classes do provide this sort of access, as in Outer.this.method(), so I think the lack of super.super. was just an oversight.
Please don't feel too sorry for me. I have cobbled together a solution for my particular case.
I am making a subclass of javax.swing.tree.TreePath. My approach is completely different so I am using none of the fields of the original. And anyway, TreePath.lastPathComponent is private. Now TreePath.hashCode() relies on lastPathComponent, so calling hashCode() on one of my subclass objects fails. What I would like to do is override hashCode with a version that retrns the default Object.hashCode() value. That is, I really do want super.super, as in:
public int hashCode() {
return super.super.hashCode();
}
But super.super.xxx, alas, is illegal. Note that nested classes do provide this sort of access, as in Outer.this.method(), so I think the lack of super.super. was just an oversight.
Please don't feel too sorry for me. I have cobbled together a solution for my particular case.