The output you describe does not correspond to the code you posted. It actually prints

a is 14
b is 99

I’ll get to why that’s happening later. But first, I’ll rewrite your code into a form that demonstrates the relationships typically found in inheritance:

public class A {
    int a;
    int b;

    A(int i, int z) {
        a = i;
        b = z;
    }

    void abc() {
        System.out.println("a is " + a);
        System.out.println("b is " + b);
    }
}

public class B extends A {
    B() {
        super(14, 13);
    }
}

public static void main(String[] argv) throws Exception {
    B obj = new B();
    obj.abc();
}

Which gives the output

a is 14
b is 13

This is inheritance in its simplest form, and has the following characteristics:

• An instance of B contains two member variables, a and b. These variables are defined by class A.
• When you invoke the method abc() on an instance of B, the JRE determines that the method is actually defined in class A. This is known as dynamic dispatch, and is one of the key features of inheritance.

Now a modification:

public class B extends A {
    B() {
        super(14, 13);
    }

    @Override
    void abc() {
        System.out.println("b is " + b);
        System.out.println("a is " + a);
    }
}

Here I’ve overridden the method abc() in class B. When the JVM examines the class, it determines that B has defined the method, so invokes that implementation and does not look for an implementation in A.

Because B extends A, and the member variables a and b are not declared private by A, B has access to those variables. The output is:

b is 13
a is 14

Another modification:

public class B extends A {
    B() {
        super(14, 13);
        super.b = 99;
    }

    @Override
    void abc() {
        System.out.println("b is " + b);
        System.out.println("a is " + a);
    }
}

This highlights the construction chain. In an inheritance hierarchy, a class’ constructor must call a superclass’ constructor. So here, B() explicitly calls A(int,int), which implicitly calls Object().

The ordering is important: immediately after the call super(14,13), the value of member variable b is 13. However, the B() constructor changes that value, so the program prints

b is 99
a is 14

I left the assignment as super.b = 99, but in this case it could also have been just been b = 99, because class B has access to the variable defined by A. However, this form becomes important in the next revision.

Let’s bring this program one step closer to your original:

public class B extends A {

    int a = 55;
    int b = 72;

    B() {
        super(14, 13);
        super.b = 99;
    }

    @Override
    void abc() {
        System.out.println("b is " + b);
        System.out.println("a is " + a);
    }
}

In this case I’m redefining the variables a and b within class B. These definitions shadow the definitions from class A. This is where it gets tricky — and why, in production code, shadowing is a code smell.

• There are now four variables in the class instance. Two are defined by class A, and two are defined by class B.
• The code in class B will ignore the variables defined by A
• Unless you explicitly prefix the variable reference with super

So, after construction, here are the four variables:

• a, defined by A, with the value 14
• b, defined by A, with the value 99
• a, defined by B, with the value 55
• b, defined by B, with the value 72

Note that the variable b defined by A was explicitly changed by B‘s constructor, after it was assigned by A‘s constructor, because B‘s constructor referred to it with super.

However, the definition of method abc() in B doesn’t prefix those variables with super, so it will print the values of the variables defined by B:

b is 72
a is 55

Last step: I remove the definition of function abc() from class B.

public class B extends A {

    int a = 55;
    int b = 72;

    B() {
        super(14, 13);
        super.b = 99;
    }
}

Now the JRE again invokes the function defined in A. However, this implementation only has access to the two variables that are also defined by A; it has no knowledge of the two variables defined by B even though they exist within the object instance. So the output is

a is 14
b is 99

Why isn’t b 13? Because the constructor for B explicitly referenced the variable defined by A.

Anyone who feels the need to add references to specs should feel free to do so; I don’t think they’re necessary.