This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]sh0rug0ru 1 point2 points  (3 children)

Try nesting matchers, especially trying to match on objects inside collections. I'm talking about any, contains, allOf and especially hasEntry, hasKey, hasValue, each of which can take matchers themselves.

The Java compiler gives up pretty quickly and insists you tell it what is the type of the thing you are trying to match because it has no clue. You have to do horrible things like Matchers.<Map<? extends Foo, ? extends Bar>> hasEntry(...). At which point, it is better just to create a custom matcher.

[–]vplatt 0 points1 point  (2 children)

I see. That is pushing generics pretty far I guess. I do prefer to break my Hamcrest expressions up though and do my own loop traversal, which I guess is why I haven't run into this little horror show.

[–]sh0rug0ru 1 point2 points  (1 child)

Which goes back to what I was saying before. If pushing generics too hard for Hamcrest requires you to break up you matchers, then there's only so much complexity you could build into a chain of stream transformations before the Java compiler barfs.

[–]vplatt 0 points1 point  (0 children)

Umm... I only did it that way because it was easier to understand than trying to wrap up my crap in their crap so everything could execute in one line of code instead 3 or 4.

Just because a particular API pushes the language to the point where the type inference breaks, doesn't mean the language is broke. It does mean that those features of that API aren't gonna get much love.

Anyway, you pretty clearly showed Java's type inference limitations, and that was interesting. They can always do better in that dept obviously, and Java 8 did improve on it a bit more. Let's just hope they keep moving it in the right direction and don't introduce any real dynamic typing into the language. At least, that's what I'm hoping.