Generate same forwarding methods as javac for method with Java 5 covariant return type

[GoogleCodeExporter]

import org.junit.*; // JUnit 4.5
import static org.mockito.Mockito.*; // Mockito 1.7

public class CovariantMockTestCase
{
    public static interface ReturnsObject {
        Object callMe();
    }

    public static interface ReturnsString extends ReturnsObject {
        @Override // Java 5 covariant override of method from parent 
interface
        String callMe();
    }

    @Test 
    public void returnFoo1() {
        ReturnsObject mock = mock(ReturnsObject.class);
        when(mock.callMe()).thenReturn("foo");
        Assert.assertEquals("foo", mock.callMe()); // Passes
    }

    @Test 
    public void returnFoo2() {
        ReturnsString mock = mock(ReturnsString.class);
        when(mock.callMe()).thenReturn("foo");
        Assert.assertEquals("foo", mock.callMe()); // Passes
    }

    @Test 
    public void returnFoo3() {
        ReturnsObject mock = mock(ReturnsString.class);
        when(mock.callMe()).thenReturn("foo");
        Assert.assertEquals("foo", mock.callMe()); // Passes
    }

    @Test 
    public void returnFoo4() {
        ReturnsString mock = mock(ReturnsString.class);
        when(mock.callMe()).thenReturn("foo"); // covariant override not 
generated
        ReturnsObject mock2 = mock; // Switch to base type to call 
covariant override
        Assert.assertEquals("foo", mock2.callMe()); // Fails: 
java.lang.AssertionError: expected:<foo> but was:<null>
    }
}

Original issue reported on code.google.com by lyog...@gmail.com on 26 Jun 2009 at 7:37

[GoogleCodeExporter]

Very well spotted. Thanks for reporting!

There might be a way to get verify() and stubbing smarter around 
covariant-issue but
I have a feeling it's not something easy to fix.

Original comment by szcze...@gmail.com on 26 Jun 2009 at 9:46

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 9 Jul 2009 at 12:53

• Added labels: Milestone-Release1.9

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 20 Oct 2009 at 7:43

• Removed labels: Milestone-Release1.9

[GoogleCodeExporter]

Any chance of getting this fixed ? 
I spend a lot of time staring at my failing tests before i found this bug..

Original comment by janss...@gmail.com on 6 Nov 2009 at 5:31

[GoogleCodeExporter]

Hi,

There might be a way though I don't know how to fix it. The reflection doesn't 
tell
me if there is a covariant override :(

Original comment by szcze...@gmail.com on 6 Nov 2009 at 11:04

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 14 Feb 2010 at 10:13

• Changed state: WontFix

[GoogleCodeExporter]

Is there a workaround for this?
And why is this marked wontfix?
(Jmockit documents that they support this
http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix)

Original comment by alexande...@gmail.com on 21 Dec 2010 at 6:19

[GoogleCodeExporter]

>Is there a workaround for this?

Explicit cast / avoiding cast should help.

>And why is this marked wontfix?

It's hard to fix & the case is a pretty edge one.

>Jmockit documents that they support this

Good for them ;) If you're keen on this feature please contribute: 
http://code.google.com/p/mockito/wiki/HowToContribute

Cheers!

Original comment by szcze...@gmail.com on 21 Dec 2010 at 7:44

[GoogleCodeExporter]

I started looking at the issue. It seems the original problem is gone with the 
latest java5 or java6.

Can you submit a test case that reproduces the problem?

Original comment by szcze...@gmail.com on 2 Jan 2011 at 9:27

• Changed state: New

[GoogleCodeExporter]

Original comment by szcze...@gmail.com on 2 Jan 2011 at 9:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I guess it's a bridge method problem again

Original comment by brice.du...@gmail.com on 3 Jan 2011 at 12:33

[GoogleCodeExporter]

> It seems the original problem is gone with the latest java5 or java6

I'm still reproducing the behavior described in the comments in the original 
test code

Java(TM) SE Runtime Environment (build 1.6.0_23-b05)
Mockito 1.8.5

The real-world cases where this is annoying are where the system under test 
uses multiple references to the mocked object, with different static types.  
You have to know which methods are called via which static type in order to set 
up mocks that work.  

Original comment by lyog...@gmail.com on 3 Jan 2011 at 3:18

[GoogleCodeExporter]

That's weird. The test case reported early to this issue is a part of mockito 
suite. Have a look: 
http://code.google.com/p/mockito/source/browse/test/org/mockitousage/bugs/Covari
antOverrideTest.java?r=08b1c5713d5460dbfa3c69d938564730e4491b2c

Interestingly this test passes ok: 
http://hudson.ramfelt.se/job/Mockito/529/testReport/org.mockitousage.bugs/Covari
antOverrideTest

Can you upgrade to latest Mockito and confirm it still fails?

Original comment by szcze...@gmail.com on 3 Jan 2011 at 9:57

[GoogleCodeExporter]

Comparing your passing test case to the failing original, what I see is that 
the failing assertEquals on like 50 was removed.  The method is called, but the 
result is not checked.

Original comment by lyog...@gmail.com on 4 Jan 2011 at 12:30

[GoogleCodeExporter]

Another test case:

import org.mockito.Mock;   
import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;

public class ExampleTest extends TestCase {
  public interface Factory {}
  public interface ExtendedFactory extends Factory {}

  public interface SomeInterface {
    Factory factory();
  }

  public interface SomeSubInterface extends SomeInterface {
    @Override
    ExtendedFactory factory();
  }

  @Mock SomeSubInterface someSubInterface;
  @Mock ExtendedFactory extendedFactory;

  @Override
  protected void setUp() throws Exception {
    super.setUp();
    MockitoAnnotations.initMocks(this);

    Mockito.when(someSubInterface.factory()).thenReturn(extendedFactory);
    //Mockito.when(((SomeInterface)someSubInterface).factory()).thenReturn(extendedFactory);                                                                                                               
  }

  public void testNothing() {
    SomeInterface si = someSubInterface;
    assertTrue(si.factory() != null);
  }
}

Original comment by alexande...@gmail.com on 4 Jan 2011 at 1:55

[GoogleCodeExporter]

@lyogman, good catch, the test is a bit different. However, if you look closer, 
the stubbing is replaced with verfication so that debugging is easier. The 
exposed mechanism of bridge methods is exactly the same.

@alexander.kjeldaas, your test case is working fine for latest java(1.6.0_21 or 
1.5.0_22) and latest mockito (tip version). What is your environment?

Original comment by szcze...@gmail.com on 9 Jan 2011 at 7:03

[GoogleCodeExporter]

I have yet a slightly different test case that still fails and I think is 
related:

import static org.mockito.Mockito.when;
import static org.mockito.MockitoAnnotations.initMocks;

import java.util.Iterator;

import org.junit.Before;
import org.junit.Test;
import org.mockito.Mock;

public class IterableMockInAdvancedForLoopBugTest {

    @Mock private IterableImpl<Object> mockIterable;
    @Mock private IteratorImpl<Object> mockIterator;

    @Before
    public void setUp() {
        initMocks( this );

        when( mockIterable.iterator() ).thenReturn( mockIterator );
        when( mockIterator.hasNext() ).thenReturn( false );
    }

    @Test
    public void shouldPassButFailsWithNullPointerException() {

        for( @SuppressWarnings("unused") Object o : mockIterable ) {

        }

    }

    private static interface IterableImpl<T> extends Iterable<T> {
        @Override
        public IteratorImpl<T> iterator();
    }

    private static interface IteratorImpl<T> extends Iterator<T> {
        public boolean hasNext();
        public T next();
    }

}

I'm on java1.6 update 23 and Mockito 1.8.5

Original comment by matyas.m...@gmail.com on 13 Jan 2011 at 1:43

[GoogleCodeExporter]

I tried all three of the test cases above, using Mockito 1.9.0.  None of them 
failed for me.  Therefore, I think this issue should be closed.  Is anybody 
still encountering this issue, or anything like it?

Original comment by dmwallace.nz on 28 Dec 2011 at 4:33

[GoogleCodeExporter]

Agreed, I tested it with both JDK 5 and JDK 6. I think Szczepan fixed it while 
working on issue 200.
The polymorphic issue there is also related to covariant return type.

So for now I'm marking this issue as fixed and I'll label it Release1.9-rc1.

Original comment by brice.du...@gmail.com on 1 Jan 2012 at 1:01

• Changed state: Fixed
• Added labels: Milestone-Release1.9-rc1