Sugar generation for primitive types

[GoogleCodeExporter]

Using Hamcrest with primitive types often requires auto boxing/unboxing to the 
corresponding reference types. Hidden NullPointerExceptions are just one of 
quite a few concerns regardings automatic (un)boxing, for details see 
Autoboxing is Evil [1, 2]. Therefore, static analysis tools such as the Eclipse 
Java Compiler can be configured to show warnings whenever a boxing or unboxing 
conversion takes place. 

However, markers are also put on code that is perfectly sane, e.g. 
Matchers.is(1). This is because the is() method is defined as follows:

@Factory
public static <T> Matcher<T> is(T value) { ... }

If there would be another factory method for ints, no auto boxing would be 
necessary:

@Factory
public static Matcher<Integer> is(int value) {
    return is(Integer.valueOf(value));
}

However, instead of overloading all factory methods in the source code, those 
methods could simply be generated and added to the matcher library by the sugar 
generator!

If we have an unrestricted Matcher<T> like is() we could generate and add the 
following methods to the library:

Matcher<Byte> is(byte value) {
    return is(Byte.valueOf(value));
}
Matcher<Short> is(short value) {
    return is(Short.valueOf(value));
}
Matcher<Integer> is(int value) {
    return is(Integer.valueOf(value));
}
Matcher<Long> is(long value) {
    return is(Long.valueOf(value));
}
Matcher<Float> is(float value) {
    return is(Float.valueOf(value));
}
Matcher<Double> is(double value) {
    return is(Double.valueOf(value));
}
Matcher<Boolean> is(boolean value) {
    return is(Boolean.valueOf(value));
}
Matcher<Character> is(char value) {
    return is(Character.valueOf(value));
}

When T is one of Byte, Short, Integer, Long, Float, Double, Boolean, or 
Character there would only have to be one additional method. When none of these 
types is a valid type argument, no additional methods would have to be 
generated.

[1] http://pboop.wordpress.com/2010/09/22/autoboxing-is-evil/
[2] http://tumblr.com/xzzqcggxp

Original issue reported on code.google.com by mphilipp82@gmail.com on 21 Nov 2010 at 2:46

[GoogleCodeExporter]

It sounds like this is a problem with your tool (or your configuration of your 
tool) rather than Hamcrest.  Autoboxing does exactly what it's meant to for 
Hamcrest.  I see no compelling reason to write our own implementation of a 
mechanism that's already implemented by the language.

Original comment by nat.pr...@gmail.com on 10 Feb 2011 at 7:49

• Changed state: WontFix

[GoogleCodeExporter]

Did you consider the thoughts of Nicole and me mentioned in [1] ?

Original comment by derlei...@web.de on 10 Feb 2011 at 8:25

[GoogleCodeExporter]

This is is one of the main reasons my team has decided not to go with hamcrest. 
 assertEquals handles this perfectly without having to take the performance hit 
of auto-boxing.

Original comment by per...@gmail.com on 2 Aug 2014 at 7:06