Not necessarily true anymore.Hamcrest 1.1 is full of generics goodness everywhere. Have a look at the TypeSafeMatcher, for instance:
http://www.jmock.org/javadoc/2.0.0/org/hamcrest/TypeSafeMatcher.html On 24/07/07, Shane Duan <[EMAIL PROTECTED]> wrote:
Does hamcrest supporting generics now? I had an email conversation a while ago, and did some digging myself. Because hamcrest needs to support jMock, it cannot support generics. On 7/24/07, Elizabeth Keogh <[EMAIL PROTECTED]> wrote: > > Hi Jeff, Dan, > > The breaking up of matchers is already done; I haven't started including > Hamcrest yet. > > I love working with JBehave in Java 5, and would love it even more if it > used, internally, some of the amazingness that Java 5 provides. It seems to > me that our user base is (entirely?) made up of Java 5 users. It would make > the matchers much simpler, too. > > Give me the word and I'll shift it over... :) > > Cheers, > Liz. > > > "Jeff Grigg" <[EMAIL PROTECTED]> wrote on 24/07/2007 02:20:21: > > > This strikes me as a really good idea: Making the Matcher creation > methods > > static for Java 5 and external access, and splitting them into multiple > > classes. One could still provide convenient Java 1.4 access by having > > UsingMatchers methods that forward to all the *Matchers classes. > > > > (I'm currently working towards introducing JBehave as a BDD tool in > several > > project heavily into JUnit usage. So I want to be able to use JBehave > > assertion logic from JUnit tests. I'm currently doing this with a class > I > > wrote, "public abstract class UsingMatchersTestCase extends TestCase" > that > > contains all UsingMatchers method signatures, and forwards all calls to a > > local instance of UsingMatchers. It's working pretty well for me. ...at > > least so far. ;-) > > -- JeffGrigg > > > > > > ----- Original Message ----- > > From: "Dan North" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Wednesday, April 18, 2007 8:33 AM > > Subject: Re: [jbehave-dev] Re: Splitting UsingMatchers > > > > > > > [...] > > > > > > fwiw I agree about breaking out the matchers and making them > > > statically-importable. Maybe now is the time to start looking at > hamcrest > > > compatibility, and having the wider conversation about how we can > leverage > > > the java 5 features in a gracefully-degrading way. > > > > > --- Mauro Talevi wrote: > > >> +1. > > >> > > >> Perhaps we could also make the methods static. That way, folks on > JDK1.5 > > >> can use static imports and not have to extends UsingMatchers, while > folks > > >> on JDK1.4 can keep on doing as before. > > >> Also, if static the split matchers can be invoked directly rather than > > >> via the facade of UsingMatchers. > > >> > > >> Cheers > > > > >> Elizabeth Keogh wrote: > > >>> > > >>> Hi all, > > >>> > > >>> I'm trying to add Collection and Array matchers to UsingMatchers. > > >>> > > >>> This is now a really, really big class! > > >>> > > >>> I'd like to split it up and delegate to the package-accessible > splits, > > >>> because this will make it easier to maintain. > > >>> > > >>> The split I envisage at the moment is: > > >>> > > >>> CustomMatcher (move to top level) > > >>> UsingEqualityMatchers (eq, isNull, isA) > > >>> UsingCollectionMatchers (collectionContaining) > > >>> UsingArrayMatchers (arrayContaining) > > >>> UsingLogicalMatchers (and, or) > > >>> UsingStringMatchers (contains, startsWith, endsWith) > > >>> UsingExceptions (pending, fail, todo, runAndCatch) > > >>> Ensure (ensureThat) > > >>> > > >>> I think this will also be far easier to extend than what we have now, > > >>> even if we do end up rewriting Hamcrest. > > >>> > > >>> I have also added the describe(Object arg) method to CustomMatcher, > > >>> which returns arg.toString() by default. This allows me to do neat > > >>> things like "Expected a collection containing <4> but got an > ArrayList > > >>> [5, 6, 7]". > > >>> > > >>> What do you think? > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this list please visit: > > > > http://xircles.codehaus.org/manage_email > > > -- Shane http://www.shaneduan.com --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
--------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
