Interface with variables

Question

Hello all, I have a problem that has stumped even the smartest software engineer I know. Why does the following slice of code always print out "This does not work as expected". It seems to me that the 'int' inside of the interface is implecitly final, but the compiler should throw a compiler error if that were the case. When I use the debuger packaged with JBuilder 9 the value of the 'int' is 1 as it should be when it gets to the condition, but it still enters the conditions as if it were a 0. Thank you in advance for your help.
public class instanceOfInterface {
public static void main(String argc[]) {
interfaceDef2 id = new interfaceDef2() {
public int someInt = 1;
if (id.someInt == 1) {
System.out.println("This works properly.");
else if (id.someInt == 0) {
System.out.println("This does not work as expected.");
interface interfaceDef2 {
public int someInt = 0;
}

Answer 1

No. Try the example by defining a base class with a
non static field, extending this class and referencing
the field with a reference to the subclass. Then
assign the subclass reference to a superclass variable
and do the same. You will see the same difference you
see in this example. E.g.:
public class TestFieldOverride {
public static void main(String[] args) {
Bar b = new Bar();
Foo f = new Foo();
Bar bf = f;
System.out.println("Bar i = " + b.i);
System.out.println("Bar getI = " + b.getI());
System.out.println("Foo i = " + f.i);
System.out.println("Foo getI = " + f.getI());
System.out.println("BarFoo i = " + bf.i);
System.out.println("BarFoo getI = " +
= " + bf.getI());
System.exit(0);
}Question, do you know why this is permitted? It seems to me that this behavior, if actually used in real code would quickly create a maintance nightmare. I don't think that you even need to setup a strawman argument of 'what if every class you create has an i variable to show that this could easily be very confusing to a programmer.
My only guess is so that you can create a private version of a variable that has the same name as a parent classes variable in a subclass. Thus reducing the pressure to create unique and very long names for the programmer. But for public/protected/default access member variable names shouldn't be avaliable for subclasses to override. Course it would probably break code to change it now. So it probably won't happen.