Why doesn't my primitive-type-argumented method override the wrapper-type-argumented super class method?

amarnath harish :

public class WrapperClasses{
    void overloadedMethod(Number N){
        System.out.println("Number Class Type");
    }

    void overloadedMethod(Double D){
        System.out.println("Double Wrapper Class Type");
    }

    void overloadedMethod(Long L){
        System.out.println("Long Wrapper Class Type");
    }

    public static void main(String[] args){
        int i = 21;
        WrapperClasses wr = new WrapperClasses();

        //wr.overloadedMethod(i);
    }
}

class mine extends WrapperClasses{
    void overloadedMethod(int N){
        System.out.println("Integer Class Type");
    }
    public static void main(String[] args){
        int i = 21;
        WrapperClasses wr = new mine();

        wr.overloadedMethod(i);
    }
}

This prints Number Class Type.

I understand the rules of wrapper class method overloading:

1. If you are passing a primitive data type as an argument to the method call, the compiler first checks for a method definition which takes the same data type as an argument.
2. If such a method does not exist, then it checks for a method definition which takes a larger-sized primitive data type than the passed data type. I.e., it tries to perform auto-widening conversion of the passed data type.
3. If auto-widening conversion is not possible, then it checks for a method definition which takes the corresponding wrapper class type as an argument. I.e., it tries to perform auto-boxing conversion.
4. If such a method does not exist, then it checks for a method which takes the super class type (Number or Object type) as an argument.
5. If such a method also does not exist, then the compiler gives a compile-time error.

According to rule 1, it should print Integer Class Type. What am I missing here?

Andy Turner :

At a language spec level, it is because methods with parameters which differ as being primitive and wrapped primitive types are not considered as override-equivalent. (A fancy way of saying "they just don't because the language spec says so").

But logically, they shouldn't either, at least in the case of an int parameter in a subclass "overriding" a wrapped parameter in a superclass.

By Liskov's Substitution Principle, methods in subclasses must accept at least all the parameters accepted by the method in the superclass.

If the superclass method accepts the wrapped class, it can accept null. If the subclass method were allowed only to accept int, it could not accept null, so it would not be substitutable.