Call me an idiot, but what good is java inheritance if it can’t even inherit accessors. Does that mean that you can’t inherit any methods or properties?
Maybe I just don’t know how to do it, but I’m suspicious the answer will be somewhere between “you shouldn’t do that” and “why would you want to do that?” which translates directly into “I don’t know what you’re talking about.”
Given a class “Bar” that extends class “Foo” which implements interface “DeeDum”
public interface DeeDum {
public String getDee();
public String getDum();
}
public class Foo implements DeeDum {
public String dee = "D";
public String dum;
public String getDee() { return dee; }
public String getDum() { return dum; }
}
public class Bar extends Foo {
public String dee = "DEE";
public String dum = "DUM";
}
Why doesn’t this work?
public static Bar mybar = new Bar();
Assert.assertEquals("DEE", mybar.getDee());
Assert.assertEquals("DUM", mybar.getDum());
I get “D” and null instead. In other words, Bar doesn’t inherit accessors. Somehow calling mybar.getDum() calls a static instance of class Foo and returns the static properties from the parent class. Even if the properties are overridden in the child class!
I can’t wrap my head around it. It’s the craziest thing in the world, and only slightly more deterministic than returning a randomly populated array of octal integers. Whenever I see something like this I smell a bad, deliberate design based on an incorrect pedantic notion. Still, it’s funny hearing from a crazy blind man why the sky is red, so if this is really the case, why can’t Java inherit accessors (and why did they choose such an odd alternative?)
Or am I just doing something wrong?
Fijiaaron 
I posted this on Stackoverflow.com and got several helpful comments.
http://stackoverflow.com/questions/436742/can-java-inherit-accessor-methods#436917
It turns out the problem was that I was “learning java from the Eclipse compiler” by accepting suggestions from the icons it generates on the trough.
The simple answer is that I need to set the properties in an initialization block (or constructor) , or it will, in fact point to the parent class properties (because the inherited methods do so by default, which a helpful comment and a bit of thought helped me to realize would be a can of worms.
An initialization block allows the best of both worlds, simplified compiler design, and the ability to override. Clever language designers!
I’m actually enjoying the amount of “help” I get from using a statically typed language like java, though I think an IDE could preparse a dynamic language and give most of the help you have with a static language, just by not worrying about following edge cases like variable variables.
Evidence of this is that there’s nothing stopping a static language from pre-compiling hashes (or eve n preparsing XML) and having that data available if they really wanted to. No runtime guarantees of course.
the example that works:
public class Bar extends Foo {
{
dee = "DEE";
dum = "DUM";
}
}
note the initization block.
Here’s a link about inititialization blocks:
http://www.developer.com/java/other/article.php/2238491
While you can set the parent property in the above block, it doesn’t actually create a copy for the child class.
It seems to be a non-deterministic (alphabetical, based on class name?) for multiple classes.
So if you have Bar and Baz which both extend foo and have an initialization block, it seems like both inherit the value set by Bar.