I've been using java for a long time, but just noticed an oddity. The object resolution of a cast object does not go to the subclass.

class A{
public static final String MYTYPE = "A";
A(){}
public void show(){
System.out.println("type 1:"+MYTYPE);
try{
Field f = this.getClass().getDeclaredField("MYTYPE");
System.out.println("type 2:"+f.get(this).toString());
}catch(Exception e){}
}
}

class B extends A{
public static String MYTYPE = "B";
B(){};

public static void main(String[] args){
A x = new B();
x.show();
}
}

[tzellers@twzlinux3 ~]$ java B
type 1:A
type 2:B


Has anyone a pointer explaining this failure to catch the overridden variable?

TIA
-- TWZ

The "type 1" line shows A because the variable in declared in the same scope (the same code "block") as the System.out.println instruction. The "type 2" line shows B because the object "this" refers to the the current used object which is B here.

Say what??? That makes no sense, the variable on which show is called is declared in main. For proof:

import java.lang.reflect.Field;
class A{
public static String MYTYPE = "A";
A(){}
String getType(){ return MYTYPE; }
void show(){
System.out.println("type A1a:"+MYTYPE);
System.out.println("type A1b:"+this.getType());
try{
Field f = this.getClass().getDeclaredField("MYTYPE");
System.out.println("typeA2 :"+f.get(this).toString());
}catch(Exception e){}
}
}

----
import java.lang.reflect.Field;
class B extends A{
public static String MYTYPE = "B";
B(){ super();}
String getType(){ return MYTYPE; }
void show(){
System.out.println("type B1a:"+MYTYPE);
System.out.println("type B1b:"+this.getType());
try{
Field f = this.getClass().getDeclaredField("MYTYPE");
System.out.println("typeB2 :"+f.get(this).toString());
}catch(Exception e){}
}

----

class C extends B{
public static String MYTYPE = "C";
C(){ super();}
public static void main(String[] argc){
A x = new C();
System.out.println("----------------------------------");
System.out.println("var x");
x.show();
B y = new C();
System.out.println("----------------------------------");
System.out.println("var y");
y.show();
}
}
[tzellers@localhost ~]$ java C
----------------------------------
var x
type B1a:B
type B1b:B
typeB2 :C
----------------------------------
var y
type B1a:B
type B1b:B
typeB2 :C

The one and only distinction between x and y is the cast type. It doesn't matter. What appears to matter is that a superclass method will not see the subclass's class (static) variables when run on a subclass object. I'm looking for a cogent explanation as to why that I can remember in an intelligent way - and hopefully one that will convince me that it *has* to be that way other than my growing unease that java's OO semantics are broken here.

-- TWZ

I will agree with alpha on this, it is clearly a scoping issue between your system.out and your getclass call. You got to remember that when you extend a class and don't provide an overriding method (your show method) it will have to chain up to its parent until it finds one. In your most recent case it means going up to Class B where it prints the system.out.print for the Class B, then when you get to your try and ask for the field using getClass, you are asking for a reference to itself which would be of type C, so that is why you are getting B for your MTYPE, You are asking for its type which it is currently a type "B" (the name) and then you are asking for an instance of itself using getClass so you are getting "C" because after all it is a "C" class.

Lets run through the first example you provided....




When you execute your show method here, it looks for the show method of Class B, doesn't find it. Cascades up into A where it locates the Show method (as you know)... it prints the variable for A in the System print because it is local scope to the object. Then in your try you get a reference to the current class, which is back in B, so it is of type "B" and returns the value of the field local to B. Hence you get the A and the B in order.

Just to help you understand that, override show in your class B definition and you will notice it never gets to A and will never print the system.print line local to A.

Alpha was on the right track with this. I don't think anything is broken here. It is following proper inheritance rules.

That is just my two cents.

This post has been edited by Martyr2: 17 Aug, 2007 - 01:32 PM

Thanks Marty and alpha, but neither of your explanations are to my liking. But it's java, not that your explanations are wrong. My expectation in OO is that the binding of an characteristic would follow the object under reference, not its immediate lexical representation.

For the last few years I haven't done much java since my work has more been bound to php and perl. But looking over some old code I found cases where I've run into this before - and "solved" it by creating fake accessor methods and always using them. but unfortunately having to repeat them in each subclass. That works.

It was hard to find, but in spending part of the day in research I discovered that no, I'm not crazy. Java is broken and in this case even the kludged up OO in PHP and Perl is better:

http://articles.techrepublic.com.com/5100-22_11-5031837.html

Polymorphism in java is broken with regard to characteristics (variables) It won't stop me from using java - way too much of the world is "invested" in it with way too many good utilities exist, and I have a workaround and now clearly understand the problem. But it leaves a bad taste in my mouth. Ruby is coming (though it'll take a good many years to get here, yet).

-- TWZ

Uhhh... as even the author and one of the other programmers mentioned in the comments those examples were of poor design and the programmers fault. The entire article you cited was "gotchas" as in programmers often make these mistakes. I still don't see a fault with the language.

Even after reading the article these facts remain steadfast....

1) They are talking scope, which both Alpha and I have told you about.
2) Those examples don't discuss anything about using getclass like you are using.
3) It is a fault of the programmer, not the language. Again these are the rules of inheritance.

And since you appear to not "like" our answers doesn't make them false. For some reason I think you are fishing for an answer that supports your hypothesis.

Sorry, we just state what we see in the code. Either way I am glad you have seemed to find your answer... whatever that may be.

Good luck to you.

This post has been edited by Martyr2: 17 Aug, 2007 - 11:53 PM

Well, this is now in the realm of abstract discussion rather than the practical as I have "my answer".

It is indeed a question of "scope". Further reading shows me that there are others who have problems with java's "early binding" of static and final entities.

The question is which is "right" OO? Binding an entity name to the lexical scope or binding it to the referenced object scope? The very name "object oriented" implies a preference for the object. Class variables are not strictly OO since it violates encapsulation which is some (weak IMO) justification for the lexical binding, but from the object perspective the class variable should be just another named characteristic, and it simply isn't - the overridden static variable cannot be referenced (outside of reflection on the object) by methods available (from superclasses) to its class.

My core contention is that

there exists non nulls (this, name) |
this.name != this.getClass().getDeclaredField("name").getObject(this)

is wrong from an OO standpoint.


-- TWZ