Stub behavior not called when interface overrides generic method and mock is cast as a super-interface

[GoogleCodeExporter]

What steps will reproduce the problem?
interface Vehicle {}
class Car implements Vehicle {}
interface Operator<T extends Vehicle>
{
    void start(T vehicle);
}
interface Driver extends Operator<Car>
{
    @Override
    void start(Car car); //this override exposes the issue
}
class ExpectedException extends RuntimeException {}

Driver driver = mock(Driver.class);
doThrow(new ExpectedException()).when(driver).start(Matchers.<Car>any());
((Operator<Car>) driver).start(new Car());

What is the expected output? What do you see instead?
ExpectedException should be thrown. Instead, the stub behavior is not called. 
Removing the override in Driver is a workaround, however this workaround is not 
viable in all real-world cases (e.g. MyBatis mapper interface, 3rd party 
interface).

What version of the product are you using? On what operating system?
I've tried 1.9.5 as well as master on GitHub (1.9.8 under development, I 
believe). Java 1.7.0_21 (Oracle). Mac OS X.

Please provide any additional information below.
I tried the fix for issue 434 (https://github.com/mockito/mockito/pull/33 ) and 
it does not fix this issue.

Original issue reported on code.google.com by hansen.c...@gmail.com on 27 Feb 2014 at 6:41

[GoogleCodeExporter]

Workaround is to mock out super-interface call in addition to mocking out the 
overriding interface. In the example above it would be:
doThrow(new ExpectedException()).when(((Operator<Car>) 
driver)).start(Matchers.<Car>any());

Original comment by hansen.c...@gmail.com on 27 Feb 2014 at 6:45

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hey thanks, that may be related to bridge methods.

We are experimenting bridge methods hacks a bit in the following PR, 
https://github.com/mockito/mockito/pull/33.
Though, there's still regressions with the current status of this PR.

Original comment by brice.du...@gmail.com on 18 Mar 2014 at 7:38

[GoogleCodeExporter]

As I mentioned in the additional information section, I did try the pull 
request you mentioned and it did not resolve the issue. I don't think it's a 
bridge method in this case, but I could be wrong.

Original comment by hansen.c...@gmail.com on 19 Mar 2014 at 5:38

[GoogleCodeExporter]

In this case it is not related to the bridge method but problem is with 
InvocationMatcher. I think that it will be fixed together with PR33

Original comment by albers...@gmail.com on 19 Mar 2014 at 5:56

[GoogleCodeExporter]

OK, if this PR is fixing it. Please add a new test case.

I will find some time tonight to have a better look a the problem.

Original comment by brice.du...@gmail.com on 19 Mar 2014 at 6:23