views:

71

answers:

1

Hey guys. In a place I have a method with a generic "VT extends String". Obviously this generates a warning: The type parameter VT should not be bounded by the final type String. Final types cannot be further extended. Do you know if there's a way to suppress this warning (Eclipse)? If you're wondering how I got to have this:

import java.util.ArrayList;
import java.util.List;

class A<T> {
T value;
B<? super T> b;

void method() {
    b.method(value,new ArrayList<T>());
}}

interface B<X> {
<VT extends X> VT method(VT p, List<VT> lst);
}

// works fine
class C implements B<Number> {
public <VT extends Number> VT method(final VT p, final List<VT> lst) {
    return p;
}}

// causes warning
class D implements B<String> {
public <VT extends String> VT method(final VT p, final List<VT> lst) {
    return p;
}}

// error: The type E must implement the inherited abstract method B<String>.method(VT, List<VT>)
class E implements B<String> {
@SuppressWarnings("unchecked")
public String method(final String p, final List<String> lst) {
    return p;
}}

Thanks! Cristian

+2  A: 

Your code doesn't compile, but here's something similar, which I assume is what you want:

class A<T>{
    T value;
    B<? super T> b;
    void method(){
        b.method(value);
    }
}
interface B<X>{
    <VT extends X> VT method(VT p);
}
// works fine
class C implements B<Number>{
    public <VT extends Number> VT method(VT p){return p;}
}
// causes warning
class D implements B<String>{
    public <VT extends String> VT method(VT p){return p;}
}

Seeing that you don't have a choice to saying extends String here, I'd say this is a bug in Eclipse. Furthermore, Eclipse can usually suggest an appropriate SuppressWarnings, but doesn't here. (Another bug?)

What you can do is change the return and argument type to String and then suppress the (irrelevant) type safety warning it causes:

// no warnings
class D implements B<String>{
    @SuppressWarnings("unchecked")
    public String method(String p){return p;}
}
gustafc
Sorry for non-compile. I just fast-adapted it from my code. The return type in B,C,D should be void, but this does not affect my situation. Your solution is interesting and I would use it but it doesn't seem to work. If I do this I will get the error: "D does not implement method". Seems such a method does not have the same signature.
Cristian Vrabie
Actually it compiles just fine. My bad in explaining my code. I have 2 parameters to the method. That's when it fails. http://pastebin.com/RETLMnCj
Cristian Vrabie
Can you update your code in the original question so that it compiles and works like your situation? Still, the type parameter to `B.method` is pointless here (it would only make sense if you were expecting to return a value of the same type as the argument). You could just say `void method(X x)` in `B`. I'd recommend you to remove the type parameters to `method` if you control that code, rather than doing weird warning suppressions.
gustafc
You're absolutely right! Thanks!
Cristian Vrabie
OK, looking at the pastebin code, I'd recommend you to give `method` the signature `void method(X x, List<? extends X> lst)` - no warnings, no compile errors, easier on the eyes.
gustafc