Rafael T Rafael T - 1 month ago 7
Java Question

Override a method in Java generically

If I have a base class like this I couldn't change:

public abstract class A {
public abstract Object get(int i);
}


and I try to extend it with a Class B like this:

public class B extends A{
@Override
public String get(int i){
//impl
return "SomeString";
}
}


everything is ok. But my attempt to make it use more generic fails if I try:

public class C extends A{
@Override
public <T extends Object> T get(int i){
//impl
return (T)someObj;
}
}


I can't think of any reason, why this should be dissallowed. In my understanding the generic type
T
is bound to an Object - which is the requested return type of
A
. If I can put
String
or
AnyObject
as return type inside
B
, why I'm not allowed to put
<T extends Object> T
inside my
C
class?

Another Strange behavior in my point of View is that an additional Method like this:

public class D extends A{

@Override
public Object get(int i){
//impl
}

public <T extends Object> T get(int i){
//impl
}
}


Is also not allowed with the hint of a
DuplicateMethod
. This one, at least confuses me, and I think java should make a decision: Is it the SAME return Type, why not allow overriding, and if it is not, I should be able to add this Method. To tell me its the same, but I cannot take it to Override is very weired in common sense

Answer

JLS # 8.4.2. Method Signature

The signature of a method m1 is a subsignature of the signature of a method m2 if either:

  • m2 has the same signature as m1, or

  • the signature of m1 is the same as the erasure (ยง4.6) of the signature of m2.

As per above rule as your parent do not have an erasure and your child has one so it is not a valid overriding.

JLS#8.4.8.3. Requirements in Overriding and Hiding

Example 8.4.8.3-4. Erasure Affects Overriding

A class cannot have two member methods with the same name and type erasure:

class C<T> {
    T id (T x) {...}
}
class D extends C<String> {
    Object id(Object x) {...}
}

This is illegal since D.id(Object) is a member of D, C.id(String) is declared in a supertype of D, and:

  • The two methods have the same name, id
  • C.id(String) is accessible to D
  • The signature of D.id(Object) is not a subsignature of that of C.id(String)
  • The two methods have the same erasure

Two different methods of a class may not override methods with the same erasure:

 class C<T> {
     T id(T x) {...}
 }
 interface I<T> {
     T id(T x);
 }
 class D extends C<String> implements I<Integer> {
    public String  id(String x)  {...}
    public Integer id(Integer x) {...}
 }

This is also illegal, since D.id(String) is a member of D, D.id(Integer) is declared in D, and:

  • The two methods have the same name, id
  • D.id(Integer) is accessible to D
  • The two methods have different signatures (and neither is a subsignature of the other)
  • D.id(String) overrides C.id(String) and D.id(Integer) overrides I.id(Integer) yet the two overridden methods have the same erasure

Also It gives example of a case where it is allowed from super to child

The notion of subsignature is designed to express a relationship between two methods whose signatures are not identical, but in which one may override the other. Specifically, it allows a method whose signature does not use generic types to override any generified version of that method. This is important so that library designers may freely generify methods independently of clients that define subclasses or subinterfaces of the library.

Consider the example:

class CollectionConverter {
List toList(Collection c) {...}
}
class Overrider extends CollectionConverter {
 List toList(Collection c) {...}

}

Now, assume this code was written before the introduction of generics, and now the author of class CollectionConverter decides to generify the code, thus:

 class CollectionConverter {
   <T> List<T> toList(Collection<T> c) {...}
 }

Without special dispensation, Overrider.toList would no longer override CollectionConverter.toList. Instead, the code would be illegal. This would significantly inhibit the use of generics, since library writers would hesitate to migrate existing code.