How to Correctly return something that extends from a class and implements an interface?

Question

Background

This question is for both Java and Android developers.

On Android, I want to have a function that returns something that extends from View and implements Checkable, both are part of the Android API.

What I've tried

After searching a bit here and on other places on the Internet, I've found this solution:

private <T extends View & Checkable> T get() {
    return (T) mView;
}

Note that mView is of any type that extends View (and there are plenty) but I guarantee that it implements Checkable since only those types get to be there.

This shows a warning of "Type safety: Unchecked cast from View to T" , but that's not the problem. The problem is that I can't use this method correctly, for example:

View v=get(); //this works fine
Checkable c=get(); // this shows error

the second line shows the error:

Bound mismatch: The generic method get() of type ... is not applicable for the arguments (). The inferred type Checkable&View is not a valid substitute for the bounded parameter

So I've tried using "," instead of "&" . same error.

However, when I use "," and reverse the order , I get a warning "The type parameter View is hiding the type View" , and both lines work fine.

This is the code:

private <T extends Checkable, View> T get() {
    return null;
}

private void foo() {
    final View v = get(); // this works fine
    final Checkable c = get();// this works fine too
}

However, when I send the returned type to other functions, they don't get the type itself as something that extends the class and the interface, and need casting all the time (to View).

The question

What is the correct way to do it?

If the last way I've shown is the correct one, why do I get a warning about it? and why is the order important if there is always a max of one class to extend ?

Answer 1

Before I dive into generics.... Why don't you just introduce a CheckableView and return that type?

public class CheckableView extends View implements Checkable {
}


 private CheckableView getCheckableView() {
     return checkableView;
 }

If View would be an interface it works:

interface View {}
interface Checkable {}
class CheckableView implements Checkable, View {}

public class Main {

    private static CheckableView checkableView;

    private static  <T extends View & Checkable> T get() {
        return (T) checkableView;
    }

    public static void main(String[] args) {
        View view = Main.get();
        Checkable checkable = Main.get();
    }
}

I think the problem in understanding generics is that T extends View & Checkable in the actual case does not mean that you can return any type that extends View and implements Checkable.

It means that the client can cast the returned type to any type that extends View and implements Checkable.

A client could do something like this:

class CheckableView extends View implements Checkable {}
class OtherView extends View implements Checkable {}

private static  <T extends View & Checkable> T get() {
    return (T) checkableView;
}

OtherView otherView = Main.get();
CheckableView checkableView = Main.get();

but what do you want to do now with the implementation?

 private <T extends View & Checkable> T get() {
      return ...;
 }

What should this method return? If you return a CheckableView the compiler will say that you must cast it to T, because a client might cast it to any type T. But this also means that you will get an Unchecked cast from CheckableView to T warning, because if the client casts it to any other type than CheckableView, e.g. OhterView, you will get a ClassCastException.

Since the get method implementor can not know to which type the client will ever cast it, he can not determine which object to return.

And if the the implementor returns a specific object (e.g. CheckableView), than the client can only cast it to that type. So why does the implementor not change the method signature to return exactly that type? .... or introduce a special type or interface for this case?

Maybe this is a solution for you

Create an interface that the get method will return, e.g.

public interface CheckableView {
}

Change the get method to return an CheckableView

private CheckableView get() {
}

Write an adapter that adapts your Views that implement Checkable to the CheckableView

public class CheckableViewAdapter<T extends View & Checkable> implements CheckableView {

    private T checkableView;

    public  CheckableViewAdapter(T checkableView) {
        this.checkableView = checkableView;
    }
}

Now you can create instances of a CheckableView for every View that implements Checkable

class SomeView extends View implements Checkable {}

SomeView someView = ...;
CheckableView checkableView = new CheckableViewAdapter<SomeView>(someView);

Add the methods that a client of the get method needs to the CheckableView interface and implement it in the CheckableViewAdapter.

public interface CheckableView {
     public void bringToFront();
}

public class CheckableViewAdapter<T extends View & Checkable> implements CheckableView {

    private T checkableView;

    public  CheckableViewAdapter(T checkableView) {
        this.checkableView = checkableView;
    }

        public void bringToFront(){
            checkableView.bringToFront();
        }
}

or just

public interface CheckableView {
     public View getView();
     public Checkable getCheckable();
}

Answer 2

You get the error, because the type inferred for the parameter T at the second call site, i.e. Checkable c = get(), is simply Checkable, as the error message correctly reports.

If you force the call to use a compatible type View & Checkable, it will compile. To do that, you must supply the type explicitly, e.g.:

private <T extends View & Checkable> T get() {
   return (T) mView;
}

private <T extends View & Checkable> void useGeneric() {
    View v = this.get(); // no need for an explicit type
    Checkable c = this.<T>get(); // an explicit type needed
    T t = this.get(); // best way
}

private void useSpecific() {
    class Specific extends View implements Checkable {}
    Checkable c = this.<Specific>get(); // risk of ClassCastException
    Specific s = this.get(); // best way; risk of ClassCastException
}

The fact that in case of assigning to a class it doesn't require an explicit type, while it requires one in the interface case, looks to me like a type inferrence algorithm artifact, a class / interface asymetry.