Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Java name clash, have the same erasure, neither hides the other

I am getting this name clash error and i don't know how should i solve the problem. I have two classes and i am using overloaded method "createSensors". To simplify here is the code that generates the problem:

public abstract class ClassA {
    public static List<Sensor> createSensors(Collection<? extends ClassA> list) {
        List<Sensor> sensors = new ArrayList<Sensor>();
        for (ClassA s : list) {
           sensors.add(s.getSensor());
        }
        return sensors;
    }
}

public abstract class ClassB extends ClassA {
    public static List<Sensor> createSensors(Collection<? extends ClassB> list) {
        List<Sensor> sensors = new ArrayList<Sensor>();
        for (ClassB s : list) {
           sensors.add(s.getSensor());
        }
        return sensors;
   }
}
like image 640
user506246 Avatar asked Dec 22 '12 12:12

user506246


People also ask

What is name clashing in Java?

This answer is not useful. Show activity on this post. At runtime, the parameter types are replaced by Object . So saveAll(Collection<?>) and saveAll(Collection<MyClass>) are transformed to saveAll(Collection) . This is a name clash.

What is erasure of method in Java?

Generics were introduced to the Java language to provide tighter type checks at compile time and to support generic programming. To implement generics, the Java compiler applies type erasure to: Replace all type parameters in generic types with their bounds or Object if the type parameters are unbounded.


2 Answers

General answer :

Apart from the problem of the same implementation here, the core of the problem is that, somewhat barbaric, "method A and Method B have the same erasure".

What makes it a complicated question is that we generally don't (at least I did not this very morning) know a lot about "Type Erasure".

To make it short :

Parametric types perform type check at compile time (to ensure type correctness) but forget their type parameters at runtime (to avoid the generation of underlying methods).

This sounds at the same time simple and puzzling. Best way to understand it is to refer to the following literature :

  1. What is a reifiable type ?
  2. How and under what conditions is erasure performed ?
  3. Have you any idea/examples about what it could imply in my coding life ?
  4. Well that's odd and I don't really like it but I'm curious why they did that ...

Hope that'll help you as much as it helped me.

Specific answer :

In your case

public abstract class ClassA {
    public static List<Sensor> createSensors(Collection<? extends ClassA> list) {
        //do stuff
    }
}

public abstract class ClassB extends ClassA {
    public static List<Sensor> createSensors(Collection<? extends ClassB> list) {
        //do other stuff
   }
}

will be "transformed" by javac to

public abstract class ClassA {
    public static List createSensors(Collection list) {
        //do stuff
    }
}

public abstract class ClassB extends ClassA {
    public static List createSensors(Collection list) {
        //do other stuff
   }
}

where one clearly can't override the other (not the same type parameter) but end up being exactly the same at runtime (no way for your program to choose which one to use).

Enough of this problem, how to solve it ? You may proceed with one of the following approach :

  • Use different names : createASensors and createBSensors this approach is the most obvious but would seem a little less elegant.

  • Add a parameter : createSensors(Collection<? extends ClassA> list, ClassA typeDefiner) this approach can seem barbaric but is a little less elegant but is the one used in java.util.List for the method <T> T[] toArray(T[] a).

like image 152
Ar3s Avatar answered Nov 15 '22 13:11

Ar3s


The general solution is to use different names. These methods could be in classes without an inheritance relationship as these are not instance methods.

As pointed out, the method implementation in the question are the same (typo excepted).

(This issue with overloading is often confused with erasure of runtime types. Overloading is a link-time rather than a dynamic issue, so could be easily fixed in the language. It's just not a particularly useful change, and not a good idea to encourage overloading.)

like image 42
Tom Hawtin - tackline Avatar answered Nov 15 '22 12:11

Tom Hawtin - tackline