How to use (primitive) autoboxing/widening with Hamcrest?

I came across https://code.google.com/p/hamcrest/issues/detail?id=130 to add some sugar syntax for Hamcrest matchers. But the idea was rejected by the Hamcrest developers.

Any other smart ideas to make tests better readable by avoiding having to type L behind longs?

@Test
public void test1() {
    int actual = 1;
    assertThat(actual, is(1));
}

@Test
public void test2() {
    long actual = 1L;
    assertThat(actual, is(1)); // fails as expected is <1> but result was <1L> 
    // assertThat(actual, is(1L)); off course works..
}

@Test
public void test3() {
    Long actual = new Long(1);
    assertThat(actual, is(1)); // fails as expected is <1> but result was <1L>
}

UPDATE

See also below the differences when comparing e.g. int and long using default Java laguage (==), standard junit assert (assertTrue) and the hamcrest is() method. It seems odd hamcrest doest not supporting matching/comparing long vs int and the rest is.

@Test
public void test2() {
    long actual = 1L;
    int expected = 1;
    assertTrue(expected == actual); // std java succeeds
    assertEquals(expected, actual); // std junit succeeds
    assertThat(actual, is(expected)); // hamcrest fails: Expected: is <1> but: was <1L>
}

Answer

This is totally unrelated to the issue you linked which is about addressing faulty static analyzers and was correctly rejected. The issue you’re experiencing is common in Java when mixing primitive types.

To avoid typing that L you’d have to provide overloaded versions of all the matchers–not just is. Consider these examples:

assertThat(longValue, greaterThan(1));
assertThat(longList, contains(1, 2, 3));

Update

You can easily add your own overloaded versions to perform the conversion:

public static Matcher<Long> is(Integer value) {
    return org.hamcrest.core.Is.is(value.longValue());
}

Of course, now that you have one to convert from int to long you’ll want ones for float and double:

public static Matcher<Long> is(Float value) {
    return org.hamcrest.core.Is.is(value.longValue());
}

public static Matcher<Long> is(Double value) {
    return org.hamcrest.core.Is.is(value.longValue());
}

Since Java won’t automatically convert from byte to Integer*, you also needs versions for byte and short. That’s ugly enough, but what about casting to the other types, e.g., from int to double?

public static Matcher<Double> is(Integer value) {
    return org.hamcrest.core.Is.is(value.doubleValue());
}

Compile Error: Duplicate method is(Integer)

Uh oh! These won’t work because Java doesn’t allow you to overload methods based on the return type. You’ll have to declare these methods in separate classes which I leave to you.

Given the giant mess this would create, I doubt the Hamcrest authors would be open to such an addition given the low payoff. Honestly, you’re much better off being explicit by using 1L and 1.0 as needed.

* Though the compiler will convert from byte to int which could be boxed to Integer.