Java overriding bug?

[Yakov]

The code below prints Good Bye and false. Why it does not print Mary and true?
(If you change the var declaration to B obj = new B() - it works fine. )


class A {
public boolean b_flag=false;
public String str_Flag="Hello";
}

class B extends A {
public boolean b_flag=false;
public String str_Flag="Good Bye";
public String toString(){
return "B.toString() String:" + str_Flag + "B: boolean: " + b_flag;
}

}

public class VariableOverridingTest {
public static void main(String[] args) {
A obj = new B(); // Prints Good Bye and false. Why?
// B obj = new B(); // Prints Mary and true
obj.str_Flag="Mary";
obj.b_flag=true;

System.out.println(obj);

}
}

 

[David Hilsee]

The code below prints Good Bye and false. Why it does not print Mary and true?
(If you change the var declaration to B obj = new B() - it works fine. )


class A {
public boolean b_flag=false;
public String str_Flag="Hello";
}

class B extends A {
public boolean b_flag=false;
public String str_Flag="Good Bye";
public String toString(){
return "B.toString() String:" + str_Flag + "B: boolean: " + b_flag;
}

}

public class VariableOverridingTest {
public static void main(String[] args) {
A obj = new B(); // Prints Good Bye and false. Why?
// B obj = new B(); // Prints Mary and true
obj.str_Flag="Mary";
obj.b_flag=true;

System.out.println(obj);

}
}

There are two separate members named b_flag and two separate members named
str_Flag. The toString() method builds a String using the members stored in
the instance of B, not the base (A). If you modify the members in A, that
does not affect the String that is returned by toString(), because it is not
using those members of A. Were you expecting your modification of A's
b_flag to change the value of B's b_flag?

 

[Yakov]

There are two separate members named b_flag and two separate members named
str_Flag. The toString() method builds a String using the members stored in
the instance of B, not the base (A). If you modify the members in A, that
does not affect the String that is returned by toString(), because it is not
using those members of A. Were you expecting your modification of A's
b_flag to change the value of B's b_flag?

When I run this program using a debugger, I see two separate members
of each variable. I'm just wondering if Java has such thing as
variables overriding?
Based on my example, there is not. I wonder if this is described
somewhere in Java doc?

 

[David Hilsee]

When I run this program using a debugger, I see two separate members
of each variable. I'm just wondering if Java has such thing as
variables overriding?
Based on my example, there is not. I wonder if this is described
somewhere in Java doc?

No, there is no such thing. I don't know of any resource that explains why
this is not provided in Java. A basic tutorial might cover the behavior.

 

[Frank]

When I run this program using a debugger, I see two separate members
of each variable. I'm just wondering if Java has such thing as
variables overriding?
Based on my example, there is not. I wonder if this is described
somewhere in Java doc?

You should never make your attributes visible, but write
accessor/mutator methods, which can be overridden.

Redefining fields from a superclass is called variable hiding btw, in
case you want to look it up. Never used it for anything myself, but
figure it may be a powerful techique for something..

 

[Chris Uppal]

Redefining fields from a superclass [...]
Never used it for anything myself, but
figure it may be a powerful techique for something..

Yes, creating hard-to-find bugs...

;-)

For Yakov, the real authority here is the Java Language Specification (version
2), normally abbreviated to JLS2 or JLS by posters in this newsgroup. You can
buy it as a book, or it is on Sun's website somewhere in both PDF and HTML
forms.

-- chris

 

[Usenet]

Redefining fields from a superclass [...]
Never used it for anything myself, but
figure it may be a powerful techique for something..

Yes, creating hard-to-find bugs...

;-)

I've occasionally found it handy when the type of an attribute becomes more
derived as the containing class becomes more derived, e.g.

class Foo { Bar b; }
class FooDerived extends Foo { BarDerived b; }
etc.

The most-derived Foo's constructor creates a "b" of the proper type, and
calls a protected constructor to set its super's b, which call *its* super's
protected constructor, etc.

This becomes unnecessary in 1.5, though, since there you can define a getB()
method with a covariant return type.

 

[Chris Uppal]

The most-derived Foo's constructor creates a "b" of the proper type, and
calls a protected constructor to set its super's b, which call *its*
super's protected constructor, etc.

So you end up with an object holding several references to the same instance of
"BarDerived", but held in several fields of different (but related) types, all
with the same name ? I can see that the regularity is appealing, but overall
it sounds like an invitation to confusion to me. Do you see a specific benefit
in giving all the fields the same name ?

-- chris

 

[Mike Schilling]

So you end up with an object holding several references to the same
instance of
"BarDerived", but held in several fields of different (but related) types,
all
with the same name ? I can see that the regularity is appealing, but
overall
it sounds like an invitation to confusion to me. Do you see a specific
benefit
in giving all the fields the same name ?

1. There's really no confusion introduced. Other than the constructor
logic, there's never a need to know about any of the "b"s other than this.b,
which is of the proper type.

2. It saves inventing new names for each member of the hierarchy.

3. It's actually easier to code each Foo*, since they all access this.b.
There's no need to remember "I'm in FooStandard.java now, so it's
this.bStandard... ".

But, as I mentioned before, in 1.5 this.getB(), with FooXXX defining BarXXX
getB(), is a much superior solution.

 

[Yakov]

For Yakov, the real authority here is the Java Language Specification (version

2), normally abbreviated to JLS2 or JLS by posters in this newsgroup. You can
buy it as a book, or it is on Sun's website somewhere in both PDF and HTML
forms.

-- chris

You're right, you should not take for granted something that exists in
other object-oriented languages

I found a short note about this feature in Sun's Java tutorial over
here:
http://java.sun.com/docs/books/tutorial/java/javaOO/subclass.html

 

[Tony Morris]

Class fields cannot be overridden, only methods.

 

[Tony Morris]

Based on my example, there is not. I wonder if this is described

somewhere in Java doc?

You are right, there is no such thing as "field overriding".
It is explained in the Java Language Specification Second Edition.
The Java API Specification is not the relevant place for these kind of
language details.

 

[Thomas G. Marshall]

Mike Schilling coughed up:

...

Sometimes you show up as Mike Schilling. And other times, you're "usenet".
Why?

 

[Mike Schilling]

Mike Schilling coughed up:

Sometimes you show up as Mike Schilling. And other times, you're
"usenet".
Why?

"Usenet" was pilot error in configuring the newsreader on a new machine. I
should be back to being Mike from now on.