Hamcrest and the Google Web Toolkit
Pascal Muetschard
I've wanted to use Hamcrest with GWT and so I have worked on porting
the core and library functionality to GWT. Attached is a patch that
provides exactly that. Can you guys review this, give feedback on it,
and - hopefully - eventually get it committed? The patch is taken from
revision 292 from within http://hamcrest.googlecode.com/svn/trunk.
Below is a short list of explanations for some of the changes. Note
that no functional/API changes were made.
Changes in Core:
- Added an exclude property to the Factory annotation that will allow
constructor methods to exclude themselves from the GWT target, if they
use classes that are not translatable (see .core.Is)
- Added a "delegator" in internal for the java.lang.reflect.Array
class, since that class is not part of GWT. The .internal.ArrayAccess
class simply delegates all its methods to the java.lang.reflect.Array
class, whereas the GWT jar will replace it with its own
implementation. This delegator is used by the core.IsEqual
and .internal.ArrayIterator classes.
- Removed the dependancy on regex in the org.hamcrest.core.DescribedAs
class.
Changes in Generator:
- Added the funcationality described by the change to the Factory
annotation class above. The tool now takes an optional target
parameter, which is then checked against the exclude list of each
factory method.
Changes in Library:
- Since GWT does not support reflection, the TypeSafeMatcher
functionality can not be (directly) supported. However, since there
are many useful matchers extending this class, the GWT jar will
replace it with an "empty" class and will then "inject" classes in
between the current hierarchy. To allow for this injection, empty
classes were added that sit in between the TypeSafeMatcher parent
class and the implementing matchers. For example, the hierarchy for
the IsArray matcher was changed from
IsArray -> TypeSafeMatcher -> BaseMatcher
to
IsArray -> ArrayTypeSafeMatcher -> TypeSafeMatcher -> BaseMatcher.
This allows GWT to replace ArrayTypeSafeMatcher with its own version,
which then knows that it is checking for an array at compile time
(similarily, the StringTypeSafeMatcher knows to check for a String,
etc.)
- Because Character's isWhitespace method is not part of GWT, a
delegator was added to the StringTypeSafeMatcher for this. This is for
the IsEqualIgnoringWhiteSpace matcher.
- GWT does not support the cloning of arrays, so every instance of
clone on an array was replaced by constructing a new array and
System.arraycopying in the values. This should have the same end
effect, since the clone on the array is shallow in the JVM.
Thanks
--
Pascal Muetschard
Nat Pryce
if GWT was a first-class supported platform, alongside plain ol' Java,
PHP, Objective C, Python and the rest.
I have some concerns (sorry, not had time to look through the patch yet).
1) The TypeSafeMatcher implements vital functionality -- type checking
and null checking. How do you make the matchers safe with a
do-nothing implementation? Perhaps we need to revisit how that is
implemented and, instead, force subclasses to pass the expected class
to the super constructor. The whole injection thing makes me
uncomfortable -- it looks like a potential maintenance and testing
problem for the future. Which brings me to...
2) How can we ensure future changes to Hamcrest don't break the GWT
version? Can we make the build compile to Javascript and run tests in
GWT somehow?
--Nat
2008/8/26 Pascal Muetschard <pmuet...@google.com>:
Pascal Muetschard
0. About making the GWT version independent of the Java version. There is actually nearly no GWT only code in my patch. The only "GWT only" code is for the TypeSafeMatcher things, which I will expand on later. From core, the only thing needed to make GWT work was to "override" the implementation of StringDescription. If we do make GWT's version independent, I see a lot of duplication of effort.
1. About TypeSafeMatcher. Yes, checking for the right type and null is an important part of those matchers and is, of course, maintained in GWT as well - we wouldn't want the matchers to fail with an ClassCastException... Here is the problem: GWT does not have reflection (or at least only very very partial reflection). So, this means that Class.isAssignableFrom and Class.isInstance are not available. On the other hand, the "instanceof" operator is. Now, to use the instanceof operator, we need to know the type at compile time. The funny thing is, for all of the library matchers that extend TypeSafeMatcher, we do know the type at compile time. So, in order to not loose the functionality of all those matchers, I added "intermediate" classes, such as StringTypeSafeMatcher, which explicitly state at compile time what type they are looking for. This means that when running in plain old Java, the TypeSafeMatcher does all the work using reflection (as it does now) and the StringTypeSafeMatcher and its cohorts are empty. Whereas for GWT, the TypeSafeMatcher is empty and the StringTypeSafeMatcher and its cohorts do all the work since at compile time they will use "item instanceof <whatever>". I hope that makes more sense.
2. This is a very good question. I have been thinking about this and the best solution would be to do a JS compile of the GWT library in ant. However, this means adding a dependency in the build libraries on GWT (which might not be that bad) and at least an additional 30seconds of build time, which sucks since a clean build including running junit currently takes less than 10 seconds. If we can live with both (we can always make the GWT compile an optional operation for the all target) I will be happy to add that to the ant script.
--
Pascal Muetschard
Nat Pryce
> Thank you for your feedback. Here are some clarifications:
I'd prefer to share as much as possible, ideally everything, between
the GWT and Java versions.
> 1. About TypeSafeMatcher. Yes, checking for the right type and null is an
> important part of those matchers and is, of course, maintained in GWT...
...
> GWT does not have reflection (or at least only very
> very partial reflection). So, this means that Class.isAssignableFrom and
> Class.isInstance are not available.
That's a pain.
> On the other hand, the "instanceof" operator is.
How strange, since they do the same thing and Javascript is entirely dynamic.
> Now, to use the instanceof operator, we need to know the type
> at compile time. The funny thing is, for all of the library matchers that
> extend TypeSafeMatcher, we do know the type at compile time. So, in order to
> not loose the functionality of all those matchers, I added "intermediate"
> classes, such as StringTypeSafeMatcher, which explicitly state at compile
> time what type they are looking for. This means that when running in plain
> old Java, the TypeSafeMatcher does all the work using reflection (as it does
> now) and the StringTypeSafeMatcher and its cohorts are empty. Whereas for
> GWT, the TypeSafeMatcher is empty and the StringTypeSafeMatcher and its
> cohorts do all the work since at compile time they will use "item instanceof
> <whatever>". I hope that makes more sense.
That's what I'm uncomfortable with. I'd actually prefer that the GWT
and Java versions were the same.
I think that the matchers provided by the Hamcrest should extend
StringTypeSafeMatcher, DoubleTypeSafeMatcher etc. to be GWT-compatible
and TypeSafeMatcher<T> should remain in the library for Java
programmers to extend when writing their own matchers.
(Actually I'd prefer the names StringMatcher, DoubleMatcher, etc.)
> 2. This is a very good question. I have been thinking about this and the
> best solution would be to do a JS compile of the GWT library in ant.
> However, this means adding a dependency in the build libraries on GWT (which
> might not be that bad) and at least an additional 30seconds of build time,
> which sucks since a clean build including running junit currently takes less
> than 10 seconds. If we can live with both (we can always make the GWT
> compile an optional operation for the all target) I will be happy to add
> that to the ant script.
An separate build target that compiles and tests the GWT version would
be great. Adding the GWT libraries as a dependency is not a problem.
--Nat
Steve Freeman
On 26 Aug 2008, at 23:31, Nat Pryce wrote:
> I think that the matchers provided by the Hamcrest should extend
> StringTypeSafeMatcher, DoubleTypeSafeMatcher etc. to be GWT-compatible
> and TypeSafeMatcher<T> should remain in the library for Java
> programmers to extend when writing their own matchers.
>
> (Actually I'd prefer the names StringMatcher, DoubleMatcher, etc.)
So, GWT users might write their own type safe extensions, but not
using the TypeSafeMatcher? We'd need to make clear which parts are GWT-
safe and which not.
>> 2. This is a very good question. I have been thinking about this
>> and the
>> best solution would be to do a JS compile of the GWT library in ant.
>> However, this means adding a dependency in the build libraries on
>> GWT (which
>> might not be that bad) and at least an additional 30seconds of
>> build time,
>> which sucks since a clean build including running junit currently
>> takes less
>> than 10 seconds. If we can live with both (we can always make the GWT
>> compile an optional operation for the all target) I will be happy
>> to add
>> that to the ant script.
>
> An separate build target that compiles and tests the GWT version would
> be great. Adding the GWT libraries as a dependency is not a problem.
Again, we should be clear about what the different environments need
to run. It should be obvious to "normal" users that they don't need
the GWT libraries, so we should make an effort to package nicely.
We should also resolve the difference reporting API before this
happens (or during).
S.
Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006
M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627
Pascal Muetschard
> the GWT and Java versions.
> That's a pain.
Yeah... i know.
>> On the other hand, the "instanceof" operator is.
> How strange, since they do the same thing and Javascript is entirely dynamic.
> That's what I'm uncomfortable with. I'd actually prefer that the GWT
> and Java versions were the same.
>
> StringTypeSafeMatcher, DoubleTypeSafeMatcher etc. to be GWT-compatible
> and TypeSafeMatcher<T> should remain in the library for Java
> programmers to extend when writing their own matchers.
>
> (Actually I'd prefer the names StringMatcher, DoubleMatcher, etc.)
> An separate build target that compiles and tests the GWT version would
> be great. Adding the GWT libraries as a dependency is not a problem.
> Again, we should be clear about what the different environments need
> to run. It should be obvious to "normal" users that they don't need
> the GWT libraries, so we should make an effort to package nicely.
Pascal Muetschard
Pascal Muetschard
Anyways, I have a "working version" of JMock for GWT and I would like you to take a look at it as well. I haven't much tested it yet (especially the code generation part) but I think it looks promising.
There is one issue though. JMock relies heavily on reflection, which as we now well know is not there in GWT. While the mocking is hiding the need for reflection with interfaces (Imposteriser, et al), a lot of the rest of the code depends on java.lang.reflect.Method. I have added a class to replace that one within JMock, put the problem is that there is this one interface org.jmock.syntax.MethodClause that announces to the "outside world" that we are using reflection. In the attached patch, I have changed the method signature of that one method in that one public interface, which means that it could break other people's code... I have not yet found a workaround for this problem and was hoping you guys might help me out here...
It would be great to have both Hamcrest and JMock in GWT, wouldn't you agree? :) I'm certainly hurting for it. Attached are the two patches for Hamcrest and JMock along with a simple GWT test case showing the simple Publisher-Subscriber example and how a JMock unit test would look like in GWT.
I will be gone for the next month with very, very limited access to email, so I appologize in advance for not being able to respond quickly to any questions/feedback you may have.
--
Pascal Muetschard
Steve Freeman
Nat's away for a couple of weeks, so we can discuss when everyone gets
back.
S
Steve Freeman
Pascal Muetschard
Also, any idea's and feedback about my work on JMock?
--
Pascal Muetschard <pmuet...@google.com>
Nat Pryce
being done if it's in the issue tracker than if it's an attachment in
an email.
--Nat
2008/10/2 Pascal Muetschard <pmuet...@google.com>:
Pascal Muetschard
Some additional changes: merged with latest trunk revision (I think 322), gwt source tree is now in the same format as all other source folders.
Please review as soon as you can :).
Pascal Muetschard <pmuet...@google.com>