hasItem (v1.2) used with local variable compiles in Eclipse but not using Ant

[GoogleCodeExporter]

Steps to Reproduce

1. Unzip the attached file and import into Eclipse (I used Eclipse 3.4)
2. Build the project in eclipse. The build should be successful.
3. Open a terminal/command prompt to the root of the project folder
4. Run the following command 'ant build'

What I expected to happen

I expected that the project would build successfully from Ant because it builds 
ok in Eclipse.

What happened instead

Instead I got the following error message:

  C:\hamcresttest\TestHasItem.java:68: cannot find symbol
  symbol  : method assertThat(java.util.Set<hamcresttest.TestHasItem.Something>,org.hamcrest.Matcher<java.lang.Iterable<? super 
java.lang.Object>>)
  location: class hamcresttest.TestHasItem
  assertThat(things, hasItem(hasValue));

Additional Notes:

If I replace the hamcrest jar with version 1.1, the program compiles fine from 
Eclipse and from Ant.

Original issue reported on code.google.com by as.da...@gmail.com on 29 May 2009 at 1:30

Attachments:

• testHasItem.zip

[GoogleCodeExporter]

More Additional Notes:

I should have added what java compiler versions I've tried.

The following javac version and OS combinations have proved unsuccessful in 
compiling 
the above project.

1.5.0_18 on Ubuntu 9.04 (I updated the build script to target 1.5)
1.6.0_04 on Windows XP SP3
1.6.0_13 on Windows XP SP3
1.6.0_10 on Ubuntu 8.04

Original comment by as.da...@gmail.com on 1 Jun 2009 at 11:30

[GoogleCodeExporter]

I did some further testing to ensure that Ant wasn't the cause of my problems 
(it 
isn't). 

But it may be helpful that in the 'steps to reproduce' instead of running 'ant 
build' 
it would be more transparent to:

cd src
javac -cp ../lib/hamcrest-all-1.2.jar hamcresttest/TestHasItem.java

If you change the above to reference hamcrest-all-1.1.jar, then everything 
compiles 
fine.

Original comment by as.da...@gmail.com on 1 Jun 2009 at 11:39

[GoogleCodeExporter]

I've written a small test (see attached patch) that compiles fine in Eclipse 
(all 
tests pass) but not using the hamcrest build script (tests don't compile).

The test contains three 'assertMatches'. The first two compile fine, it's the 
third 
that has problems. However, the error returned is not 'exactly' the same as it 
with 
the above project etc. In fact I believe that the compilation error can be 
worked 
around by passing a command line argument to the ant javac task.

(attached patch was made against /tags/1.2)

Original comment by as.da...@gmail.com on 2 Jun 2009 at 3:52

Attachments:

• hamcrest_isCollectionContaining_generic_test.diff

[GoogleCodeExporter]

In 1.1 the below code was necessary to get around a java capture issue (got the 
solution from 
http://weblogs.java.net/blog/johnsmart/archive/2008/04/on_the_subtle_u.html):

final Matcher<Foo> propertyMatcher = hasProperty("bar", equalTo("a"));
assertThat(listOfFoos, hasItem(propertyMatcher));

After playing around with the above project with 1.2, I found that no longer do 
I have to assign the 'hasProperty' matcher to 
a local variable BUT I do need to assign the 'hasItem' to a local variable. 

The above code becomes:

Matcher<Iterable<? super Foo>> collectionMatcher = hasItem(hasProperty("bar", 
equalTo("a")));
assertThat(listOfFoors, collectionMatcher);

_my preference_ is the former method, mostly because Matcher<Iterable<? super 
Foo>> is not the sort of thing I want littering 
my tests.

*BUT THERE IS ANOTHER WAY*

change the signature of:

  assertThat(T, Matcher<? super T>) 

to:

 assertThat(T, Matcher<?>)

I know I'm not the first to suggest the above (I didn't find the conclusion to 
the argument so forgive me if I'm barking up 
the wrong tree). I understand that the first signature gives type safety, 
whereas the second does not.

My argument is, is type safety really a concern with the sort of code that most 
typically calls 'assertThat'. 

My understanding regarding the pro's for type safety (in a very general sense) 
is the confidence you get from knowing that 
your application isn't going to die on some obscure branch of code because you 
passed a string when you expected an integer.

But isn't it testing code that typically calls assertThat? That sort of code 
dies all the time. And its expected. I can't 
imagine writing a bunch of testing code and then not running it after its 
compiled to see if tests pass/fail. And (I could be 
wrong here) I would expect that if I passed a matcher of the wrong type to the 
type unsafe assertThat, that the matcher would 
fail because of a type mismatch.

Using the new signature, the above code example can be written as:

assertThat(aListOfFoos, hasItems(hasProperty("foo", equalTo("a"))));

I believe that it gives the best of both worlds. You still get type safe 
matchers (just not a type safe assertThat) and you 
can write concise testing code (one of the major attractive features of 
hamcrest).

Original comment by as.da...@gmail.com on 4 Jun 2009 at 1:26

[GoogleCodeExporter]

Isn't this more of an issue for JUnit not Hamcrest, since assertThat is part of
JUnit?  Just been running into the same issues and equally frustrated...still 
can't
get it to work in both Eclipse and Ant/JavaC.  

Did you ever talk to the JUnit guys?

Original comment by aochs...@gmail.com on 17 Sep 2009 at 10:04

[GoogleCodeExporter]

We have been talking to JUnit. We think we've now come up with a compromise 
that suits us all, which we have to 
put through a release cycle.

Original comment by smgfree...@gmail.com on 18 Sep 2009 at 6:25

[GoogleCodeExporter]

Note: this is also an issue in Eclipse. Eclipse contains its own java compiler. 
If something doesn't compile 
in javac it should not compile in Eclipse (or vice versa: I guess there could 
be a bug in javac).

Also note: a reason for static typing on assert that is to let auto-completion 
in the IDE only suggest 
appropriate matchers. This makes it much easier to find the matcher you need 
from the Matchers class. 

Original comment by nat.pr...@gmail.com on 18 Sep 2009 at 8:03

[GoogleCodeExporter]

Is this fixed in 1.3RC0 by any chance?

Original comment by davidgrant on 22 Jun 2010 at 10:53

[GoogleCodeExporter]

tagging

Original comment by t.denley on 12 May 2012 at 10:54

• Added labels: Java

[GoogleCodeExporter]

Related to issue 100.

Original comment by qualidaf...@gmail.com on 12 Dec 2012 at 12:19