Develop Reference

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;
}
}

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 :
What is a reifiable type ?
How and under what conditions is erasure performed ?
Have you any idea/examples about what it could imply in my coding life ?
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).

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.)

Check the project setting and compiler version of the project. Right click on project --> Properties --> Java Compiler. Make sure compliance setting are up to date. I had this problem when compliance settings were set to 1.4 instead 1.6

Java generics compilation error - The method method(Class<capture#1-of ? extends Interface>) in the type <type> is not applicable for the arguments

Last Thursday someone at work showed me a compile error that I wasn't able to fix in a clean way and it has been bothering me ever since.
The problem is generics related and I've reconstructed a simplified version of the code that generates the compile error. The error occurs in the very last line of code shown below.
I've been looking all over the interwebs but can't seem to find a decent explanation why the Java compiler doesn't accept the code. I guess that if it were to allow the code, it would be possible the create a class cast issue in Bar.operationOnBar(), but I don't see how.
Could someone please enlighten me why this doesn't compile?
public interface Interface {
}
public class Type implements Interface {
}
public class Bar<T> {
public Bar(Class<T> clazz) {
}
public void operationOnBar(Class<T> arg){
}
}
public class Foo {
public <T> Bar<T> bar(Class<T> clazz){
return new Bar<T>(clazz);
}
public static void main(String[] args) {
Class<? extends Interface> extendsInterfaceClazz = Type.class;
new Foo().bar(extendsInterfaceClazz).operationOnBar(Type.class);
}
}
Compile Error on the second line of Foo.main():
The method operationOnBar(Class<capture#1-of ? extends Interface>) in the type Bar<capture#1-of ? extends Interface> is not applicable for the arguments (Class<Type>)
Btw. I've solved it by downcasting Type.class to Class, this way the compiler is unable to see that the generic type of Class is "Type" instead of "? extends Interface".

A little advice: when you are not sure why compiler prohibits some generic-related conversion, replace generic classes in question with List<T>. Then it would be easy to find an example that breaks type safety.
This replacement is correct since currently Java doesn't provide a way to conduct any a priory knowledge about possible behaviours of generic classes (i.e. it lacks a way to specify covariance and contravariance of generic classes in their declarations, as in C# 4 and Scala). Therefore Class<T> and List<T> are equivalent for the compiler with respect to their possible behaviours, and compiler has to prohibit conversions that can cause problems with List<T> for other generic classes as well.
In your case:
public class Bar<T> {
private List<T> l;
public Bar(List<T> l) {
this.l = l;
}
public void operationOnBar(List<T> arg) {
l.addAll(arg);
}
}
List<Type1> l1 = new ArrayList<Type1>();
List<? extends Interface> l2 = l1;
List<Type2> l3 = Arrays.asList(new Type2());
new Foo().bar(l2).operationOnBar(l3);
Type1 t = l1.get(0); // Oops!

You also can change the signature of the method operationOnBar to:
public void operationOnBar(Class<? extends Interface> arg){

You would agree that this shouldn't compile:
1 Class<? extends Interface> clazz = AnotherType.class;
2 new Foo().bar(clazz).operationOnBar(Type.class);
The problem is javac is a little dumb; when compiling line#2, all it knows about variable clazz is its declared type; it forgets the concrete type it was assigned to. So what is assigned to clazz at line#1 doesn't matter, compiler must reject line#2.
We can imagine a smarter compiler that can track the concrete types, then your code can be compiled, as it is obviously safe and correct.
Since that's not the case, sometimes programmers know more about types than the compiler, it is necessary that programmers do casts to convince the compiler.

The general way to deal with these sorts of problems is to introduce a generic argument for the repeated type, which generally means introducing a new generic method (a class would do as well, but isn't necessary).
public static void main(String[] args) {
fn(Type.class);
}
private static <T extends Interface> void fn(Class<T> extendsInterfaceClazz) {
new Foo().bar(extendsInterfaceClazz).operationOnBar(extendsInterfaceClazz);
}
Not really related to the question, but I would suggest using reflection sparingly. It is very, very rarely a good solution.

Adding a Generic allows you to override a method with a different return type?

I ran into this today and the only thing I can think is that this is a bug in the Java compiler. The following code compiles, but certainly seems incorrect (since testMethod has a differenet signature in the child but overrides the parent) and will throw class cast exceptions at runtime.
public interface TestInterface<T> {
public List<String> testMethod(); // <-- List<String>
}
public class TestClass implements TestInterface {
#Override
public List<Integer> testMethod() { // <-- List<Integer> overriding List<String>!!
return Collections.singletonList(1);
}
}
And using the above structure:
public void test() {
TestInterface<Boolean> test = new TestClass();
List<String> strings = test.testMethod();
for (String s : strings) {
System.out.println(s);
}
}
All of this compiles fine, but will obviously throw class cast exceptions if you run it.
If you remove <T> from TestInterface, or fill T in in the line TestClass implements TestInterface<T> then the code will no longer compile, which makes sense. Imo <T> should have no bearing on the compilation of testMethod since it plays no part in that method.
Maybe adding <T> to TestInterface is causing the compiler to type-erase the method signatures even though T doesn't participate in those methods...?
Does anyone know what is going on here?

If you instantiate a generic class as a raw type, all generic type parameters contained in it are going to be omitted by the compiler, hence it gives you no warnings/errors during compilation. I.e. declaring
public class TestClass implements TestInterface ...
effectively degrades the code into
public interface TestInterface {
public List testMethod();
}
public class TestClass implements TestInterface {
#Override
public List testMethod() {
return Collections.singletonList(1);
}
}
which indeed compiles fine.
A similar problem was posted a couple of weeks ago, the answer to which stating that it is not a compiler bug, rather a deliberate design decision for backward compatibility.

The way I understand it is that generics is a compiler side thing. Nothing about the generic-type information is included in the class file, it's like a compiler hack. Which is why you can easily intermingle generic-laden calls with generic-free classes and there's no problem at runtime.
I hear that all that dotnet stuff makes the generic-type information a first class citizen within the object file.
So anyway, these guys obviously know your problem better than I do, but you should consider than all that's really going on is compiler fluff.

Need derived class for java generics declaration

I've run into a sticky problem that I can't seem to solve with java generics. This is a bit complicated, but I couldn't think of a simpler scenario to illustrate the problem... Here goes:
I have a Processor class that requires a Context. There are different types of Context; most processors just need any abstract Context, but others require a specific subclass. Like this:
abstract class AbstractProcessor<C extends Context> {
public abstract void process(C context);
}
class BasicProcessor extends AbstractProcessor<Context> {
#Override
public void process(Context context) {
// ... //
}
}
class SpecificProcessor extends AbstractProcessor<SpecificContext> {
#Override
public void process(SpecificContext context) {
// ... //
}
}
Ok, cool: Processors can declare the type of Context they need, and they can assume the right type will be passed into process() without casting.
Now, I have a Dispatcher class that owns a mapping of Strings to Processors:
class Dispatcher<C extends Context> {
Map<String, AbstractProcessor<? super C>> processorMap = new HashMap<String, AbstractProcessor<? super C>>();
public void registerProcessor(String name, AbstractProcessor<? super C> processor) {
processorMap.put(name, processor);
}
public void dispatch(String name, C context) {
processorMap.get(name).process(context);
}
}
Ok, so far so good! I can create a Dispatcher for a specific type of Context, then register a batch of processors that may expect any abstraction of that Context type.
Now, here's the problem: I want the abstract Context type to own the Dispatcher, and derived Context types should be able to register additional Processors. Here's the closest I could find to a working solution, but it doesn't fully work:
class Context<C extends Context> {
private final Dispatcher<C> dispatcher = new Dispatcher<C>();
public Context() {
// every context supports the BasicProcessor
registerProcessor("basic", new BasicProcessor());
}
protected void registerProcessor(String name, AbstractProcessor<? super C> processor) {
dispatcher.registerProcessor(name, processor);
}
public void runProcessor(String name) {
dispatcher.dispatch(name, this); // ERROR: can't cast Context<C> to C
}
}
// this is totally weird, but it was the only way I could find to provide the
// SpecificContext type to the base class for use in the generic type
class SpecificContext extends Context<SpecificContext> {
public SpecificContext() {
// the SpecificContext supports the SpecificProcessor
registerProcessor("specific", new SpecificProcessor());
}
}
The problem is that I need to declare a generic Dispatcher in the base Context class, but I want the type-variable to refer to the specific derived type for each Context sub-type. I can't see a way to do this without duplicating some code in each Context subclass (specifically, the construction of the Dispatcher and the registerProcessor method). Here's what I think I really want:
Dispatcher<MyRealClass> dispatcher = new Dispatcher<MyRealClass>();
Is there a way to declare the generic type of an object with the type of the SUBCLASS of the declaring class?
Yes, I can address this problem with a little bit of low-risk casting, so this is mostly an academic question... But I'd love to find a solution that just works top-to-bottom! Can you help? How would you approach this architecture?
UPDATE:
Here's the full source, updated to incorporate Andrzej Doyle's suggestion to use <C extends Context<C>>; it still doesn't work, because Context<C> != C:
class Context<C extends Context<C>> {
private final Dispatcher<C> dispatcher = new Dispatcher<C>();
public Context() {
// every context supports the BasicProcessor
registerProcessor("basic", new BasicProcessor());
}
protected void registerProcessor(String name, AbstractProcessor<? super C> processor) {
dispatcher.registerProcessor(name, processor);
}
public void runProcessor(String name) {
dispatcher.dispatch(name, this); // ERROR: can't cast Context<C> to C
}
}
// this is totally weird, but it was the only way I could find to provide the
// SpecificContext type to the base class for use in the generic type
class SpecificContext extends Context<SpecificContext> {
public SpecificContext() {
// the SpecificContext supports the SpecificProcessor
registerProcessor("specific", new SpecificProcessor());
}
}
abstract class AbstractProcessor<C extends Context<C>> {
public abstract void process(C context);
}
class BasicProcessor extends AbstractProcessor {
#Override
public void process(Context context) {
// ... //
}
}
class SpecificProcessor extends AbstractProcessor<SpecificContext> {
#Override
public void process(SpecificContext context) {
// ... //
}
}
class Dispatcher<C extends Context<C>> {
Map<String, AbstractProcessor<? super C>> processorMap = new HashMap<String, AbstractProcessor<? super C>>();
public void registerProcessor(String name, AbstractProcessor<? super C> processor) {
processorMap.put(name, processor);
}
public void dispatch(String name, C context) {
processorMap.get(name).process(context);
}
}

It sounds like your problem is that you need the generics to refer to the specific exact type of the subclass, rather than inheriting the generic definition from the parents. Try defining your Context class as
class Context<C extends Context<C>>
Note the recursive use of the generic parameter - this is a bit hard to wrap one's head around, but it forces the subclass to refer to exactly itself. (To be honest I don't quite fully get this, but so long as you remember that it works, it works. For reference, the Enum class is defined in exactly the same way.) There's also a section in Angelika Langer's Generics FAQ that covers this.
This way the compiler gets more information about exactly what types are permissable, and should allow your case to compile without the superfluous casting.
UPDATE: Having thought about this a bit more, my above comments were along the right track but were not entirely on the money. With self-recursive generic bounds, as above, you can never really use the actual class you define them on. I'd actually never fully noticed this before, as by luck or judgement I'd apparently always used this in the right point of the class hierarchy.
But I took the time to try and get your code to compile - and realised something. The class with these bounds can never be referred to as itself, it can only ever be referred to in the context of a specific subclass. Consider the definition of BasicProcessor for example - Context appears ungenerified in the generic bounds for AbstractProcessor. To prevent a raw type from appearing, it would be necessary to define the class as:
class BasicProcessor extends AbstractProcessor<Context<Context<Context<...
This is avoided with subclasses because they incorporate the recursiveness in their definition:
class SpecificContext extends Context<SpecificContext>
I think this is fundamentally the problem here - the compiler cannot guarantee that C and Context<C> are the same types because it doesn't have the required special-casing logic to work out that the two are actually an equivalent type (which can only actually be the case when the wilcard chaining is infinite, since in any non-infinite sense the latter is always one level deeper than the first when expanded).
So it's not a great conclusion, but I think in this case your cast is needed because the compiler is unable to derive the equivalence for itself otherwise. Alternatively, if you were using a concrete subclass of Context in a similar position the compiler is able to work it out and this would not be a problem.
If you do happen to find a way to get this working without casting or having to insert a dummy subclass then please report back - but I can't see a way to do that, that would work with the syntax and semantics available to Java's generics.

Java design issue - Adding functionality to fixed classes

I have a set of classes that all need to be acted on in some (individual) way.
Ordinarily I'd just create a DoSomethingInterface with a single doSomething() method and have each class implement that method in a way that suits each class' needs. However, I cannot do that in this case as the class definitions are unmodifyable (auto-generated)
So, I reckon I need to create a set of different classes that each take one of the autogenerated classes and performs the operation on them. So, say I have 2 autogenerated classes, Class1 and Class2, I will first define a common Operator interface:
public interface Operator <TYPE>{
public void doSomething(TYPE type);
}
and then implement one of these per class
public class Class1Operator implements Operator<Class1>{
public void doSomething(Class1 type){
...
...
}
}
and
public class Class2Operator implements Operator<Class2>{
public void doSomething(Class2 type){
...
...
}
}
Ok, so far so good. Now, given that I have an object of type Class1, is there any way of getting its operator without resorting to:
public Operator getOperator(Object obj){
if(obj instanceof Class1){
return new Class1Operator();
}else if(obj instanceof Class2{
return new Class2Operator();
}
return null;
}
Which kinda seems like bad practice to me...
The only other way I can think of is by creating a map of operators to class names like so:
Map<Class, Operator> allOperators = new HashMap<Class, Operator>();
allOperators.put(Class1.class, new Class1Operator());
allOperators.put(Class2.class, new Class2Operator());
and then return the operator using:
public Operator getOperator(Object obj){
return allOperators.get(obj);
}
But this doesn't seem right (I'm not sure, are there any issues with keying an object off its class....)
Any input as to whether either of these approaches is 'correct'? or is there a more elegant solution??
Thanks

What you've implemented (the map-by-class approach) is one of the alternatives to the GoF Visitor pattern I talk about when I teach patterns. It's efficient and extendable, even at runtime. Much better than the if/else if/else hardwired approach.
The only issue with keying off the class is if the actual instances implement subtypes rather than the class type you mention; then the lookup map won't work.
If you need subtypes to be recognized, I'd recommend Aaron's approach (walk up the superclass chain), but you may also want to look at implemented interfaces as well. If you just need "exact class match", keep your getOperator simple.
Note that you have a bug in getOperator -- it should look as follows:
public Operator getOperator(Object obj){
return allOperators.get(obj.getClass());
}
One more thing... Hide your map inside another class and manage it as follows:
private Map<Class<?>, Operator<?>> map = new HashMap<Class<?>, Operator<?>>();
public <T> void register(Class<T> clazz, Operator<T> operator) {
map.put(clazz, operator);
}
This prevents anyone from registering an operator that won't work against the class it's keyed against. (You might want to use Operator as the parameter to allow an operator that's written against a superclass, but that's might not be needed)

One of the issues with building a map is that it will not support subclasses unless you register them specifically or extend your get function to look up super classes specifically.
That is to say if B inherits from A and you've registered an operator with A.class. Fetching an operator with B.class will fail, unless you change your getOperator to something like:
public Operator getOperator(Object obj){
Class<?> current = obj.getClass();
Operator op;
while((op = allOperators.get(current)) == null){
current = current.getSuperclass();
if(current == null){
/*
* We've walked all the way up the inheritance hierarcy
* and haven't found a handler.
*/
return null;
}
}
return op;
}
Once you've got a reasonable getOperator implementation, mapping classes to operators seems like a reasonable approach.

You can us Class.isAssignableFrom to get around the sub-typing issue. I use this all the time and while it is not "visitor" elegant it is quite fine in practice.

Would it be possible to create your own class that extends the generated class and then have your class implement the interface?

Have you considered this:
public Interface Operator {
public void doSomething();
}
public class Class1Operator extends Class1 implements Operator {
...
}
public class Class2Operator extends Class2 implements Operator {
...
}
But with reference to your second question of getting an operator to an object without really needing to do the "instanceof" mojo (I guess that's what is looking unclean):
I would suggest that if you can't modify your classes to your exact needs, write a wrapper around them:
public Interface Operator<T> {
public void doSomething(T obj);
}
public Interface WrappedObject<T> {
public Operator<T> getOperator();
}
public class WrappedClass1 extends Class1 implements WrappedObject<Class1> {
...
}
public class WrappedClass2 extends Class2 implements WrappedObject<Class2> {
...
}
public class Class1Operator implements Operator<Class1> {
...
}
public class Class2Operator implements Operator<Class2> {
...
}
Would that suffice your needs?
Its always a good practice to write wrappers around classes that don't match your needs perfectly, and can't be controlled by you. It helps you keep your code healthy even if these wild classes change.
Cheers,
jrh.

I'm going to say it's not possible to do just using the interface itself, based on the way Java handles generics.
In Java, generics are erased at compile time and replaced with casts.
I haven't actually checked how it works internally, but at a guess, your interface turns into this:
public interface Operator {
public void doSomething(Object type);
}
and where it's called, into this:
public class Class1Operator implements Operator{
public void doSomething(Object type){
Class1 oType = (Class1) type;
...
...
}
}
This still isn't exactly right as type will be cast after it's returned as well, plus Java bytecode doesn't actually look like Java, but you might get the general idea.
The instanceof and Map methods should work, even if they are a bit messy.