liangzai-cool / hamcrest Goto Github PK

I've been finding that the current definition of assertThat() gives
compiler errors when using polymorphism:

    public void testWibble() {
        Circle2D circle = new Circle2D(0,0,1);
        Shape circleAsShape = circle;

        assertThat(circleAsShape, equalTo(circle));          // ERROR!
        assertThat(circle,        equalTo(circleAsShape));
    }

I believe the following signature for assertThat() solves the problem:
  public static <T> void assertThat(T actual, Matcher<? extends T> matcher)


Also, given that the Matcher<T> interface doesn't actually use the 'T'
parameter, is there any reason for it having a generic type and that type
being used in assertThat()?

The autogenerated sugar should (optionally) include the EasyMock2 and
jMock1 adapters so Hamcrest can be used very easily out of the box with
these libraries.

assertThat is

<T> assertThat(T value, Matcher<T> matcher)

However, instanceOf is

public static <T> Matcher<T> instanceOf(Class<T> instanceOf)

This means that the expression

Throwable e = ...;
assertThat(e, instanceOf(AssertionError.class));

is not type-safe, according to at least the Eclipse compiler.

I'll be honest--I've spent some serious time on this one, and haven't found
a great solution.  For now, the best I've come up with is the evil:

    @SuppressWarnings("unchecked") @Test public void testSomething() {
        assertThat(e, is((Class<Throwable>)(Class<?>)AssertionError.class));
    }

I'm hoping one of you has a better idea.  Thanks!

The static factories generated in CoreMatchers and Matchers need Javadoc
documentation with examples.

Sebastien Bergmann, the maintainer of hamcrest-php, mentioned on his
original hamcrest-php blog entry that there was an implementation of
hamcrest for dotnet called hamcrest-dotnet.  The Source repository has a
directory titled hamcrest-dotnet, but there is no code.

This is an "issue" for .NET users.  Do you think it could be possible to
use db4o's Sharpen utility to translate hamcrest-java into hamcrest-dotnet?

This is a new concept in Hamcrest, orthogonal to Matchers.

A Refinement allows you to refine which part of the object is being tested.

e.g. 
assertThat(
  page, 
  inTable("sometable").cell("name", 0), // refinement 
  containsString("joe"));

This allows you to easiy navigate an object even if the methods aren't on
the object being tested (which is frequently the test).

LiFT does this well.

Hi all,

I was bit by a bug that caused ReflectiveFactoryMatcher to miss
factory methods that return a subclass of Matcher.  That is, I believe
this test should pass:

   public static class SubclassOfMatcher {
       @Factory
       public static BaseMatcher subclassMethod() {
           return null;
       }
   }

   public void testCatchesSubclasses() {
       Iterable<FactoryMethod> reader = new
ReflectiveFactoryReader(SubclassOfMatcher.class);
       Iterator<FactoryMethod> methods = reader.iterator();
       assertTrue("Expected first method", methods.hasNext());
   }

And I think all it takes to do it is reversing the way that
isAssignableFrom is used in ReflectiveFactoryMatcher:

   protected boolean isFactoryMethod(Method javaMethod) {
       return isStatic(javaMethod.getModifiers())
               && isPublic(javaMethod.getModifiers())
               && javaMethod.getAnnotation(Factory.class) != null
               && Matcher.class.isAssignableFrom(javaMethod.getReturnType());
   }

Several times I find myself trying to use assertThat to test a method that
returns boolean.  I've noticed other people make the same mistake as well.

If a test fails, we get output of the form
    Expected: <matcher.describeTo(...)>
    got: <actual.toString()>

Since the matcher necessarily knows about the object being matched
("actual") it seems to makes sense to allow the matcher to describe the
(failed) matched object as it wishes.

One suggestion is to add a method to Matcher to the effect of
describeMatched(Object/T actual), and replacing actual.toString() in the
above with matcher.describeMatched(actual) would give better reporting.
(This name can certainly be improved, maybe even just describe()? Further,
there may be better ways of implementing this to get the information into
the "got" output.)

This is useful, for example, in the case that the object being tested has a
toString() implementation that doesn't give information useful as an
expected value, but the matcher is testing some property not written into
the string.

Concrete example: an ActiveMQ queue returns something of the form
"<queue://queue_name>". If we are making an assertion about the number of
messages currently on the queue, the "got" message is entirely unhelpful,
when we read
    Expected: hasDepth(6)
    got: <queue://name>

The workaround is to add this information into the "expected" string by
caching the result of the test (in this case the queue depth) in the
matcher. This doesn't exactly feel elegant.

A default implementation in BaseMatcher could just return
actual.toString(), so however this change is implemented, it should be
fully backwards compatible.

Please fix the sources in hamcrest maven artifacts. Currently, the sources
are bundled withing main hamcrest-*.jar files rather than sources jar files
hamcrest-*-source.jar. Sources jar files are empty, what makes it hard to
use in eclipse as eclipse:eclipse plugin attaches them to project and
sources in main jar files are ignored.

In order to avoid the unchecked casts due to the varargs parameter of a
parametrized type in methods anyOf and allOf, provide some overloads

allOf(Matcher<? extends T> matcher1)
allOf(Matcher<? extends T> matcher1, Matcher<? extends T> matcher2)

etc, for 1 to N matchers.

More on the problem here
http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html#Why
%20does%20the%20compiler%20sometimes%20issue%20an%20unchecked%20warning%20when%2
0I%20invoke%20a
and at section 6.8 of Java Generics and Collections.

An alternative that seems nicer to my eye is to add 'and' and 'or' methods
to the matchers (implementing them at BaseMatcher, maybe as simple stubs
that delegate to anyOf/allOf). Then boolean expression would look like:

(instanceOf(String.class).or(instanceOf(Integer.class))).and(notNullValue())

Both changes can be implemented in a simple and backwards compatible way.

Hi, I really like the idea, that you can concatenate matchers via
foo().and(...) and/or bar().or(...) - This makes the code much more
readable than using allOf and anyOf.

E.g. compare this line:

  assertThat(input, hasAttribute("type",
equalTo("checkbox")).and(isNotSelected()));

to this:

  assertThat(input, allOf(hasAttribute("type", equalTo("checkbox")),
isNotSelected()));

The first line clearly reads more naturally - like spoken english.

I have attached a patch, which adds this feature to Hamcrest.

P.S. I already made this suggestion a month ago in a comment on issue 27,
but because nothing happend, I opened a new issue to make another try ...

Add 

Matchers.containsStrings(String substrings...)

might be more readable than

allOf(containsString("one"), containsString("two")

trunk/hamcrest-java/CHANGES.txt lists two 1.1 releases. Please resolve before 
next release.

Add support to collection matchers to allow one to test a collection
contains only a collection of specified elements.

Eg.

assertThat(collecton, onlyContains("foo","bar","baz"));

It would be nice to be able to statically import
StringDescription.toString(Matcher), but because the name collides with
Object.toString, it can't be done.  Can we instead create an alias? 
descriptionOf(Matcher)?  asString(Matcher)?

Actually, I think it would be fair to override Object.toString in
BaseMatcher, although I can see API reasons to avoid that.

<T> Matcher<T> allOf(Matcher<? extends T>... matchers)

Shouldn't it be

<T> Matcher<T> allOf(Matcher<? super T>... matchers)

instead?

Consider the following hierarchy T, T1 extends T, T2 extends T, T3 extends
T. Say T1Matcher is a matcher for T1 and T2Matcher is a matcher for T2.
Now, from the first signature, allOf(t1Matcher, t2Matcher) -> tMatcher, is
a matcher for T. But tMatcher.matches(t3) should fail, because none of
t1Matcher nor t2Matcher knows how to cope with t3 instances. I think this
error is not caught by the type system because matches expect an object
instead of a T, but it surely will be caught at runtime.

Solution: change signature as suggested. Also, according to a previous
issue posted by me, provide alternative signatures:

<T> Matcher<T> allOf(Matcher<? super T> matcher1, Matcher<? super T> matcher2)

<T> Matcher<T> allOf(Matcher<? super T> matcher1, Matcher<? super T>
matcher2, Matcher<? super T> matcher3)

in order to avoid the unchecked cast warnings from the java compiler.

The following test case fails which I think it shouldn't:
    @Before
    public void setUp() throws Exception {
    xml = parse("<root><something/></root>");
    }

    @Test
    public void testAppliesMatcherToXPathInDocument() throws Exception {
        assertThat(xml, hasXPath("//something"));
    }

This can be solved with followinf change to HasXPath.matchesSafely

try {
            if (valueMatcher == null) {
                Boolean result = (Boolean) compiledXPath.evaluate(item,
                        XPathConstants.BOOLEAN);
                return result == null ? false : result.booleanValue();
            } else {
                String result = (String) compiledXPath.evaluate(item,
                        XPathConstants.STRING);
                if (result == null) {
                    return false;
                } else {
                    return valueMatcher.matches(result);
                }
            }
        } catch (XPathExpressionException e) {
            return false;
        } 

The matching of parameter as being an instance of a type using jMock is 
currently broken due to “instanceOf” being typed with Object instead of T.

The jMock Cookbook example below will only work if the 
method "doSomething" has a signature of void doSomething(Object).

one(mock).doSomething(with(instanceOf(ActionEvent.class)));

The workaround for this issue is to cast the results of “with” 
or “instanceOf”.

See the relaxing of types in issue 10.

The hamcrest API in trunk has a IsIterableContainingInOrder matcher which 
allows me to write a test 
as follows:
assertThat(list, contains("foo", "bar"));

However if I also need to assert the size of the collection, I need to add 
another assert for the size. 
It would be great if there was another IsIterableEqualToOtherInOrder.

I'm willing to file a patch if this makes sense for hamcrest.

JavaLangMatcherAssertTest (rev. 305) fails both tests.

testFailingAssertion should include an extra negation:
    if (!thrown) {
        fail();
    }

testPassingAssertion should use a matcher that will return true:
    assert that ("Foo", startsWith("F")) // not startsWith("Far")

it uses equalTo() in greaterThanOrEqualTo() which is not correct as
equals() and compareTo() behave differently.

Example:
BigDecimal values 10.0 and 10 and not considered equal using equals() as
they differ in scale though the values are the same, but they are
considered equal when using compareTo() as the values are equal (scale is
not compared in this case).

This code also should not work as expected:
Assert.assertThat(BigDecimal.valueOf("10.0"),
OrderingComparisons.greaterThanOrEqualTo(BigDecimal.valueOf("10"));

10.0 is not greater than 10 (using compareTo()) and they are also not equal
using equals(). The funny thing is even the third comparison, 10.0 being
lower than 10 is not true. So this always results to false just because
equalTo() is used instead of compareTo() == 0 in greaterThanOrEqualTo().

I think it would be good to introduce method like compareEqualTo() to
OrderingComparisons which should be public and also used in
greaterThanOrEqualTo() instead of equalTo().

Lots of current and potential users of Hamcrest use Maven 2. To make life
easier for them, ensure we supply an appropriate M2 bundle for
distribution. (Note: this does not mean we actually have to use M2).

I was testing one of my class, specifically the equals(Object) method, and
could not get full coverage for the use case where Object is null.
this is because the isEqual matcher use areEqual(Object, Object) as
follows: (here is the code)
 private static boolean areEqual(Object o1, Object o2) {
        if (o1 == null || o2 == null) {
            return o1 == null && o2 == null;
        } else if (isArray(o1)) {
            return isArray(o2) && areArraysEqual(o1, o2);
        } else {
            return o1.equals(o2);
        }
    }

I understand why we need to check  if o1 equals null, but checking both of
them is just reimplementing the equals(Object) I would like to test.

So I went ahead and fixed my local source code of IsEqual to look like this:

private static boolean areEqual(Object o1, Object o2) {
  if (o1 == null)
        return false;

   if (isArray(o1)) 
        return isArray(o2) && areArraysEqual(o1, o2);

   return o1.equals(o2);
}

and now I get 100% coverage for my code.

allOf(Matcher...) is a fine api, but it's not typesafe (as javac likes to
remind me), and it doesn't read quite right.

Creating a Matcher.and(Matcher) syntax solves both of these problems.  I
guess that Matcher.or(Matcher) would then also have to be added.

I'd like to easily test is a string matches a regexp.

Please add releases of hamcrest into central maven repository.

Not a big problem, but hamcrest-1.1.zip doesn't contain any of the source
directories (hamcrest-*) which are in hamcrest-1.1.tgz

If you try to use the hasPropery(String,Matcher) matcher for an anonymous 
or inner class implementing a property of its interface, the matcher gets 
an IllegalAccessException and then reports a spurious failure.

For example:

interface IX {
    int getTest();
}

package com.mypackage;
public void TextX
{
    @Test
    public void test() {
        class X implements IX {
            public int getTest() {
                return 1;
            }
        }

        X x = new X();
        assertThat(x, hasProperty("test", equalTo(1)));
     }
}

This reports:

  java.lang.AssertionError: 
  Expected: hasProperty("test", <1>)
       got: <com.mypackage.TestX$1X@fd68b1>


The actual cause was an exception at:

     return readMethod != null
            && value.matches(readMethod.invoke(argument, NO_ARGUMENTS));

with Description:

    Class org.hamcrest.beans.HasPropertyWithValue can not access a member 
of class com.mypackage.TestX$1X with modifiers "public"

I would like matchers to allow the introspection of their structure.  I
need this for marshalling matchers into network messages.

--Nat

In trunk/hamcrest-java:
Could the new  IsArrayContainingSingleItem and IsIterableContainingSingleItem 
be eliminated? They 
could be satisfied by IsArrayContainingInOrder and IsIterableContainingInOrder 
if there were a way 
to construct them with single items.

The following should both compile:
        assertThat(new HashMap<X,Y>(), hasKey(new X()))
        assertThat(new HashMap(), hasKey(new X()))

They do not. Similarly for hasValue. The hasKey methods in Matchers should
be parametrised only the key type K and should return
        Matcher<? super Map<K, ?>>
instead of
        Matcher<Map<K, V>>

See the following thread for more details, and also for a more general fix
proposal.
http://groups.google.com/group/hamcrest-dev/browse_thread/thread/b3e1b118bcc6f22
0

Hi Nat,

Re issue#31 - unfortunately the change you committed didn't fix the
problem. I must say, my first reaction was that "Matcher<? super T>" would
fix the problem but it doesn't. It would be right if "T" meant "the type
expected by the method 'matches'", but the matcher defines "boolean
matches(Object item)" so T must mean something else.

I think the right answer might be:
    public static <T> void assertThat(T actual, Matcher<?> matcher)

Also, I realised my previous example had a custom class in it, so here's an
example that uses standard Java classes:

     public void testCanBeUsedPolymorphically() {
        Double doub = new Double(0);
        Number doubleAsNumber = doub;

        assertThat2(doubleAsNumber, equalTo(doub));          // ERROR!
        assertThat2(doub,           equalTo(doubleAsNumber));
    }

The AllOf constructor is defined to be:

    public AllOf(Iterable<Matcher<? extends T>> matchers) {

It should be:

    public AllOf(Iterable<? extends Matcher<? extends T>> matchers) {

The same applies to AnyOf.

 If a Matcher implementation subclasses another matcher implementation
(e.g. a subclass of AnyOf that passes specific matchers to the AnyOf
constructor), then the @Factory methods from the parent class will be
included during sugar generation. This can lead to conflicts between
methods imported from the Matchers and CoreMatchers sugar classes when used
in the same code.

Perhaps the ReflectiveFactoryReader should be calling
Class.getDeclaredMethods() instead of Class.getMethods().

I've worked around this by delegating to the core AnyOf matcher instead of
subclassing, but my preferred implementation would have been to subclass.

(This bug report applies to Hamcrest 1.1)

I've just been writing a unit test for my class's implementation of
equals() and realised that my equals method blew up if it was given a null
object to compare with (it should return false instead). My (JUnit) unit
test contained a line like:

assertThat(myObject, not(equalTo(null)));

I was surprised to discover that the unit test 'passed' before I had fixed
my equals() implementation.  It turned out that Hamcrest was not actually
calling my equals() method as it contains an optimised equals test that
skips call to my equals() implementation:

private static boolean areEqual(Object o1, Object o2) {
        if (o1 == null || o2 == null) {
            return o1 == null && o2 == null;
        } else if (isArray(o1)) {
            return isArray(o2) && areArraysEqual(o1, o2);
        } else {
            return o1.equals(o2);
        }
    }

This means that if either object is null, the call to o1.equals(Object) is
skipped completely as Hamcrest thinks it knows better.  This skips my code,
and makes my broken code look ok. 
(Code coverage didn't show this up as I had already covered the equals()
method in another non-null test.)

Hamcrest 1.1 with jUnit 4.4 and jMock 2.4.0 and IDEA 7.0.1

In the last else branch in BaseDescription.appendValue(Object) Throwable
isn't caught. This leads to hard to find bugs in tests when the hash code
of the object depends on (j)mock objects. In this case a
org.jmock.api.ExpectationError is thrown which causes an untraceable error
in the tests.

1. Create a subclass of TypeSafeMatcher
2. Use Eclipse to automatically generate stub implementations of the
abstract methods.
3. Try to construct your new subclass

Since TypeSafeMatcher.matchesSafely is protected, Eclipse makes the
overriding method protected, which means that the reflective trick used to
find the type matched fails on any subclass outside of org.hamcrest.

I suggest making TypeSafeMatcher.matchesSafely public in HEAD.

 When I download hamcrest-1.1.zip it seems to only consist of the top 
level files and the lib directory - all the source directories seem to be 
missing.

I posted this in the forum but now I realize I should have opened a request:

There appears to be a problem with the IsCollectionContaining class
which I am surprised hasn't hit a few people: here is an example of
what I want to do:

import static org.hamcrest.collection.IsCollectionContaining.hasItem;
import static org.junit.Assert.assertThat;

  @Test
  public void testSuperClass() throws Exception
  {
    final Set<Number> s = new HashSet<Number>();
    s.add(Integer.valueOf(2));
    assertThat(s, hasItem(Integer.valueOf(2)));
  }

however the above code doesn't compile becuase Integer is not Number.
The only workaraound at the moment is as follows which I think you
will agree is less than ideal.

  @Test
  public void testSuperClass() throws Exception
  {
    final Set<Number> s = new HashSet<Number>();
    s.add(Integer.valueOf(2));
    assertThat(s,
IsCollectionContaining.<Number>hasItem(Integer.valueOf(2)));
  }

There is a much neater solution. We need to change the
IsCollectionContaining class as follows:

package org.hamcrest.collection;

import static org.hamcrest.core.AllOf.allOf;
import static org.hamcrest.core.IsEqual.equalTo;

import java.util.ArrayList;
import java.util.Collection;

import org.hamcrest.Description;
import org.hamcrest.Factory;
import org.hamcrest.Matcher;
import org.hamcrest.TypeSafeMatcher;

public class IsCollectionContaining<T> extends
TypeSafeMatcher<Iterable<? super T>>
{
  private final Matcher<? extends T> elementMatcher;

  public IsCollectionContaining(final Matcher<? extends T>
elementMatcher)
  {
    this.elementMatcher = elementMatcher;
  }

  @Override
  public boolean matchesSafely(final Iterable<? super T> collection)
  {
    for (final Object item : collection)
    {
      if (elementMatcher.matches(item))
      {
        return true;
      }
    }
    return false;
  }

  public void describeTo(final Description description)
  {
    description.appendText("a collection containing
").appendDescriptionOf(elementMatcher);
  }

  @Factory
  public static <T> Matcher<Iterable<? super T>> hasItem(final
Matcher<? extends T> elementMatcher)
  {
    return new IsCollectionContaining<T>(elementMatcher);
  }

  @Factory
  public static <T> Matcher<Iterable<? super T>> hasItem(final T
element)
  {
    return hasItem(equalTo(element));
  }

  @Factory
  public static <T> Matcher<Iterable<? super T>> hasItems(final
Matcher<? extends T>... elementMatchers)
  {
    final Collection<Matcher<? extends Iterable<? super T>>> all = new
ArrayList<Matcher<? extends Iterable<? super T>>>(
        elementMatchers.length);
    for (final Matcher<? extends T> elementMatcher : elementMatchers)
    {
      all.add(hasItem(elementMatcher));
    }
    return allOf(all);
  }

  @Factory
  public static <T> Matcher<Iterable<? super T>> hasItems(final T...
elements)
  {
    final Collection<Matcher<? extends Iterable<? super T>>> all = new
ArrayList<Matcher<? extends Iterable<? super T>>>(
        elements.length);
    for (final T element : elements)
    {
      all.add(hasItem(element));
    }
    return allOf(all);
  }
} 

Extract all error description logic into a "describeMismatch" method then
let each matcher handle how it reports failure to user.

Provide a basic implementation (like the one in MatcherAssert) in
BaseMatcher but then allow extension for the more complex matchers (XPath,
Collections, Any, All) etc.

I suggest inheriting IndentedDescription from JMock 2 to allow nice nested
descriptions. I'd also like to tweak the error output a but. A rich error
report might look something like the following (I'm using hasXPath here as
an example here)

XPath expression did not return a result

Got          : <document blah>
Expectation  : has XPath "/document/title" that equals "mary had a little lamb"
But          : xpath expression did not return a result

XPath result didn't match expectation:

Got          : <document blah>
Expectation  : has XPath "/document/title" that equals "mary had a little lamb"
But          : xpath result did not match expecation ->

    Got         : "Mary had a little lambourghini"
    Expecation  : equals "Mary had a little lamb"
    But         : string differed at character 23 "...tle lamb***ourghini"

I've embellished a bit with the string diffing but it's very possible.

I'm happy to start cutting the code for this in a couple of weeks.

Currently the method declaration is as follows:
public static <T> void assertThat(T actual, Matcher<T> matcher);

This is quite limiting. It forces client code to do casting although it is
not necessary.
As an example:

1: class ExtendedObject extends Object{}
2: ExtendedObject extendedObject = new ExtendedObject();
3: Object object = extendedObject;
4: assertThat(object, is(extendedObject)); // won't compile
5: assertThat((ExtendedObject)object, is(extendedObject)); // will compile

The code on line 4 should compile, we shouldn't have to do it as on line 5.

I think changing the method declaration as follows fixes this problem:
public static <T> void assertThat(T actual, Matcher<? extends T> matcher);

Hi

Could you please add a matcher for checking if provided string is empty? By
empty I mean null or zero length.

I am aware that this check might be easily done by combining two of the
existing matchers, but I think this is a very often used matcher and it is
worth making it easier for developers.

Please see attached proposal.

Thanks.

This is more of an enhancement to make code completion nicer for users in
Eclipse. If the above method was deprecated it wouldn't appear in the auto
complete drop down. This does assume that the user has their preferences
set to not show deprecated methods when using autocomplete.

describeTo methods for higher-order matchers would read better if there
were a Description.appendSelfDescribing(SelfDescribing) method.  For
example, IsCollectionContaining.describeTo currently looks like this:

    public void describeTo(Description description) {
        description.appendText("a collection containing ");
        elementMatcher.describeTo(description);
    }

With my proposal, it would look like this:

    public void describeTo(Description description) {
        description.appendText("a collection containing ");
        description.appendSelfDescribing(elementMatcher);
    }

Which I find flows much better under the fingers.  This is the Reversing
Message pattern from Beck's Smalltalk Best Practice Patterns.

Unfortunately, doing this would add a method to an interface, breaking
current implementations of the Description interface, so this is something
best left until you're ready to make a few minor breaking changes.  

(However, this leads me to wonder if a BaseDescription method, much like
BaseMatcher, would also be useful--Description seems likely to evolve more
in the future than Matcher.)

The current "hasXPath" method does not allow XML namespace resolution, so
any test against a namespace-aware DOM Document fails.  I've attached a
patch that would add this functionality via an optional
javax.xml.namespace.NamespaceContext object.

Please see the attached diff for the code patch and unit test.  Thanks.

I'm using the latest from trunk and the following line does not compile in 
eclipse:

ArrayList<String> arrayList = new ArrayList<String>();
assertThat(arrayList, hasSize(3))

the error reported is:
The method assertThat(T, Matcher<? super T>) in the type MatcherAssert is not 
applicable for the arguments 
(ArrayList<String>, Matcher<Collection<Object>>)

Which means that I've to now do this instead:
Matcher<Collection<String>> sizeMatcher = hasSize(3);
assertThat(arrayList, sizeMatcher);

I'm using hamcrest to describe constraints on stubs in parameterized tests.
 When solving these constraints, and describing why solving failed, it's
very useful to be able to generate an example value from a Matcher, and for
many Matchers, it's much easier to do inside the class than from the
outside.  Therefore, I've locally created a ValueSet interface, which
inherits from Matcher:

public interface ValueSet<T> extends Matcher<T> {
    public T exampleValue();
}

Is, IsEqual, and IsCollectionContaining are relatively easy to extend to
support this, as are many of the numeric Matchers.  Is this of general
enough use to be worth including as an option in the base hamcrest
distribution?

Using the compiler in Eclipse 3.3 RC1, and the latest checkout of hamcrest,
the following method does not compile:

    public void testProvidesConvenientShortcutForIsInstanceOf() {
        assertMatches("should match", is(String.class), "A");
        assertDoesNotMatch("should not match", is(Integer.class), "A");
        assertDoesNotMatch("should not match", is(Integer.class), null);
    }

On each line, the error message is (for example) "The method
is(Class<Integer>) is ambiguous for the type IsTest"

If the signature of Is.is(Class) is changed to Is.is(Class<?>), this goes away.

Attached please find a patch that
  - modifies the source to eliminate dependency on JRE features that are
not emulated and therefore not supported in GWT
  - adds GWT translatable versions of a few files that are not translatable
in their Hamcrest form
  - a GWT module (org.hamcrest.Hamcrest) XML to be used in GWT modules that
whish to use Hamcrest
  - modifications to the Factory generator to allow exclusions of factories
from different targets (the only target that currently excludes anything
is, of course, the GWT target)

More details can be found in my message to the group here:
http://groups.google.com/group/hamcrest-dev/browse_thread/thread/e68d0e228e9a3bd
2/d331763300f1e040