compilation issue. isValid() method is not recognized.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Included the jar mockito-all-1.9.0.jar in a new java project
2. when(mockedList.contains(argThat(isValid()))).thenReturn("element"); - this 
line is throwing a compilation issue. isValid() method is not recognized.
3.

What is the expected output? What do you see instead?
>> compilation issue -- isValid() method is not recognized.

What version of the product are you using? On what operating system?

>>> mockito-all-1.9.0.jar on windows XP

Please provide any additional information below.

Original issue reported on code.google.com by akhilbha...@gmail.com on 25 Jan 2012 at 5:45

[GoogleCodeExporter]

Hi,
Is this a known issue. Do i need to include any other jar ?

Original comment by akhilbha...@gmail.com on 25 Jan 2012 at 5:56

[GoogleCodeExporter]

Hi

I don't think this is an issue with Mockito as it is the compiler that 
complains. You should probably try to make sure the "isValid()" method can 
actually be found by the compiler, either by looking at classpath, the imports, 
the visibility or if isValid has a generic return type make sure that the 
return type is explicitly written.

Also windows XP doesn't really interest us, however which JVM is a much more 
interesting information ;)

Hope that helps.

Original comment by brice.du...@gmail.com on 29 Jan 2012 at 5:58

[GoogleCodeExporter]

Hi,
I am using "mockito-all-1.9.0.jar".

I Don't think, its a class path issue because, i am using Eclipse IDE and i 
have included it in the build path & moreover, other methods like when, anyInt 
etc are working.

I Suspect my imports but not sure, can you check this once. I have done the 
below imports:

import static org.mockito.Matchers.anyInt;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

& i mentioned windows XP due to the format of the Question submission given 
here :). i am using java6.
please let me know, if i need to provide some more details.

Original comment by akhilbha...@gmail.com on 30 Jan 2012 at 4:28

[GoogleCodeExporter]

Hi,

Mockito doesn't have an "isValid()" method.

anyInt() doesn't expect any arguments, so basically with your imports it should 
work. While the method 
"org.mockito.Matchers.argThat(org.hamcrest.Matcher)" actually takes an Hamcrest 
matcher, so a method "isValid()" in your code should exists and return an 
Hamcrest Matcher.

Please note that at the moment Mockito only supports Hamcrest 1.1, not the 
upper versions.

Original comment by brice.du...@gmail.com on 30 Jan 2012 at 9:14

[GoogleCodeExporter]

Original comment by brice.du...@gmail.com on 1 Feb 2012 at 1:10

• Changed state: Invalid

[GoogleCodeExporter]

I use rest-assured library which uses hamcrest 1.2, so I had to go with version 
1.2. Please add support for 1.2

Original comment by ar...@identified.com on 25 Feb 2012 at 5:04

[GoogleCodeExporter]

The problem is that we should stay compatible with hamcrest 1.1. Or even move 
away the hamcrest dependency.

Original comment by brice.du...@gmail.com on 29 Feb 2012 at 12:46

[GoogleCodeExporter]

hamcrest is a great library, why do you want to move away from it? :)

Original comment by ar...@identified.com on 29 Feb 2012 at 5:27

[GoogleCodeExporter]

Yeah hamcrest is pretty good. But this means we have to spend time on 
maintaining this dependency. But I mean't is just to have an hamcrest 
integration module. Anyway this movement hasn't yet started.

But today, I don't feel the need for Hamcrest anymore. Here's why, usually we 
either need the simple mathcer or more complex matching.
For complex matching now I'd rather use an ArgumentCaptor in combination with 
FESTAssert, which is cleanier that using hamcrest.

Also I don't think this is the right issue to discuss this matter, issue 297 is 
much more relevant.

Original comment by brice.du...@gmail.com on 29 Feb 2012 at 5:38

[GoogleCodeExporter]

>hamcrest is a great library, why do you want to move away from it? :)

We want to support it in some way so that for example users can take advantage 
of their own custom matchers with mockito. However, we don't want to use 
hamcrest internally because it's a liability. The hamcrest api changes or might 
change and it impacts the end user of Mockito. That's it :)

Original comment by szcze...@gmail.com on 11 Mar 2012 at 11:29