Well, you can now …

Version 2.3.1

July 3, 2017

  • …leave equals and hashCode methods non-final in JPA entities. (Issue 170)

Version 2.3

May 24, 2017

  • …use withIgnoredAnnotations to disable specific annotations. For instance, you can disable @Nonnull to gain 100% test coverage on equals methods generated by Lombok. (Mailinglist threads 1 and 2; for more info see ‘Coverage is not 100%’)
  • …test classes derived from classes that live in a signed jar. (Issue 163)
  • …feel better about the fact that the MANIFEST.MF file is back in the EqualsVerifier jar. (It disappeared in version 2.0 or so.) (Issue 169)

Version 2.2.2

April 3, 2017

  • …avoid adding prefab values for (Issue 168)
  • …get less “Cannot inject classes into the bootstrap class loader” errors. (Also issue 168)

Version 2.2.1

January 29, 2017

  • …use single value enums as key in a Map. (Issue 166)

Version 2.2

January 14, 2017

  • …be more specific about which fields may be null, using withNonnullFields. (Issue 134)
  • …have an uninitialized static array in your class without getting a NullPointerException. (Issue 165)
  • …see more helpful error messages.

Version 2.1.8

December 13, 2016

  • …test classes that implement an abstract class that calls an abstract method in its equals or hashCode methods, when EqualsVerifier is called with usingGetClass. (Issue 161)

Version 2.1.7

November 18, 2016

  • …use single value enums again. (Issue 157; thanks Stephan!)

Version 2.1.6

October 1, 2016

  • …no longer get NullPointerExceptions in situations where annotations which are available at compile time, are not available at runtime. (Issue 153 and Issue 154)

Version 2.1.5

August 6, 2016

  • …avoid adding prefab values for java.util.Vector and java.util.Stack. (Issue 151)

Version 2.1.4

July 25, 2016

  • …use Guava’s Range with full reflection support. (Issue 150; thanks Stephan!)

Version 2.1.3

July 17, 2016

  • …use EqualsVerifier when older versions of Google Guava are on the classpath. (Issue 149)

Version 2.1.2

June 20, 2016

  • …use EqualsVerifier concurrently. (Issue 148; thanks Borys!)

Version 2.1.1

June 14, 2016

  • …not get VerifyErrors in certain situations, such as when running unit tests with coverage in IntelliJ. (Issue 147)
  • …have the (current) latest version of ByteBuddy. (Issue 145; thanks Vincent!)

Version 2.1

May 22, 2016

  • …suppress Warning.STRICT_HASHCODE to let EqualsVerifier allow hashCode methods that don’t use all the fields that are also used in equals, or even constant hashCodes. (Issue 142)
  • …assert, within a class’s equals or hashCode method, on the length of its array field. (Issue 143)
  • …get an equalsverifier.jar file without Objenesis’s meta-data in the META-INF folder. (Issue 144)
  • …no longer get a ReflectionException when EqualsVerifier is unable to read annotations on fields in certain situations. (Issue 14, Comment 21)

Version 2.0.2

April 3, 2016

  • …test classes that implement an abstract class that calls an abstract method in its equals or hashCode methods. (Issue 138)
  • …use EqualsVerifier on a JVM that doesn’t have javax.naming.Reference available. (Issue 114)

Version 2.0.1

March 13, 2016

  • …test classes that have a static final reference to a recursive data structure, without adding prefab values.
  • …test classes that have a generic parameter that extends Comparable. (Issue 136)
  • …no longer have show up on your classpath. (Issue 135; thanks Stephan!)

Version 2.0

March 6, 2016

If you’re upgrading from EqualsVerifier 1, please see the migration guide.

  • …no longer use EqualsVerifier with Java 6.
  • …no longer use EqualsVerifier.forExamples. Use #forClass or #forRelaxedEqualExamples instead.
  • …no longer use #debug() (which didn’t do anything, anyway).
  • …expect “all fields should be used” to be the default behaviour. (Issue 65)
    • Suppress Warning.ALL_FIELDS_SHOULD_BE_USED to revert back to the old behaviour.
    • #forRelaxedEqualExamples implicitly suppresses Warning.ALL_FIELDS_SHOULD_BE_USED.
    • Suppressing Warning.IDENTICAL_COPY_FOR_VERSIONED_ENTITY implicitly suppresses Warning.ALL_FIELDS_SHOULD_BE_USED.
    • #allFieldsShouldBeUsedExcept() is now removed.
    • Use #withIgnoredFields() to disregard specific fields, while expecting all remaining fields to be used in equals.
    • Use #withOnlyTheseFields() to expect that the given fields are used, and that the remaining fields are not used. (Issue 128)
  • …expect EqualsVerifier to fail when equals isn’t overridden (i.e., inherited directly from Object). (Issue 66)
    • Suppress Warning.INHERITED_DIRECTLY_FROM_OBJECT to revert back to the old behaviour.
  • …refer to the generic contents of containers, such as List and Optional, in the implementation of equals and hashCode. (Issue 84)
  • …get more useful information from the stack trace if EqualsVerifier fails.
  • …have better compatibility with Java 8. (Issue 115)
  • …know that EqualsVerifier’s code quality has been improved, as a result of adding CheckStyle and FindBugs, and doing mutation tests with PIT.

Version 1.7.8

February 26, 2016

  • …use EqualsVerifier and Java 8’s -parameters compiler option in the same project.

Version 1.7.7

January 18, 2016

  • …use EqualsVerifier together with Cobertura. (Issue 132)

Version 1.7.6

December 21, 2015

  • …have a field whose type is an interface that defines equals. (Issue 130)
  • …get 100% mutation coverage with PIT on your equals and hashCode methods. (Issue 131)

Version 1.7.5

August 29, 2015

  • …get symmetry warnings if the symmetry violation only occurs in the subclass of a versioned entity. (Issue 123, Comment 10)
  • …get a warning when the id check on a versioned entity is implemented incorrectly. (Issue 123, Comment 17)
  • …omit suppression of Warning.NONFINAL_FIELDS on classes marked @Embeddable and @MappedSuperclass. (Issue 124 and Issue 123, Comment 15)
  • …use singleton enums without null-checking. (Issue 125)

Version 1.7.4

August 17, 2015

  • …avoid adding prefab values for
  • …avoid exceptions thrown from SBT. (Issue 119)
  • …get better reporting on subclasses of versioned entities. (Issue 123)

Version 1.7.3

July 18, 2015

  • …use a protected or default-visibility cachedHashCode field with #withCachedHashCode(). (Issue 110)
  • …have a static final field with null value without getting a NullPointerException. (Issue 116)
  • …know that several things have been improved behind-the-scenes :).

Version 1.7.2

March 28, 2015

  • …use Eclipse’s JDT null annotations, including the Java 8 style type annotations.
  • …have a static field with an empty array in the class under test, without getting an ArrayIndexOutOfBoundsException. (Issue 106)
  • …revel in the fact that all dependencies have been updated (Issue 107) and that several potential bugs have been solved using PIT.

Version 1.7.1

March 11, 2015

  • …use EqualsVerifier again, without suppressing 1.7’s REFERENCE_EQUALITY warning, on classes containing:
    • certain interfaces, and classes which don’t redefine equals. (Issue 104, Comment 6)
    • a static final lambda field. (Issue 105)

Version 1.7

March 4, 2015

  • …verify classes that cached their hashCode, using #withCachedHashCode(). (Issue 60; thanks Niall!)
  • …avoid adding prefab values for several Java Collections interface classes, including SortedSet and TreeSet. (Issue 103)
  • …get an error message when you accidentally use == instead of equals on an object field inside your equals method, and suppress this using Warning.REFERENCE_EQUALITY. (Issue 104)

Version 1.6

January 17, 2015

  • …set default @Nonnull annotations on your classes (Issue 50)
    • using Findbugs’s @DefaultAnnotation or @DefaultAnnotationForFields.
    • using a JSR 305 annotation (see this StackOverflow question).
    • you can put them on the class, or on the package.
    • you can override the default by placing @Nullable or @CheckForNull on a field.
  • …verify stateless classes. (Issue 46)
  • …verify classes with stateless fields. (Issue 100 and Issue 101)
  • …verify the consistency of hashCode in a stateless object. (Issue 97)
  • …verify classes where equality is fully defined in a superclass, for example using Apache Commons’s EqualsBuilder.reflectionEquals. (Issue 102)

Version 1.5.1

December 5, 2014

  • …use EqualsVerifier when incompatible versions of ASM and/or CGLib are on the classpath. EqualsVerifier is now shipped as an “uber jar” which contains all its dependencies inside. (Issue 96)
  • …use EqualsVerifier with older versions of Google Guava on the classpath. (Issue 98)
  • …build EqualsVerifier itself using Maven instead of Ant+Ivy.

Version 1.5

August 20, 2014

  • …use EqualsVerifer in Java 8! Classes containing Java 8 language features are now supported, and prefab values for new Java 8 API classes have been added. (Issue 92)
  • …stop adding prefab values for Joda-Time and Google Guava, because EqualsVerifier now provides them for you. (Issue 83)
  • …have correct error messages when your class contains multi-dimensional arrays. (Issue 90 and Issue 94)
  • …use Arrays.equals instead of Arrays.deepEquals on Object[] fields. (Issue 94)
  • …use the super class’s equals method when specifying #allFieldsShouldBeUsed() (Issue 95; thanks Dean!)
  • …get better error messages when equals or hashCode are themselves abstract.
  • …find and understand EqualsVerifier’s unit tests more easily, as they have been heavily refactored.

Version 1.4.1

March 18, 2014

  • …pass enums through EqualsVerifier without error. (Issue 87)
  • …get more thorough reflexivity and symmetry tests, which will catch small mistakes such as the one in Issue 88.

Version 1.4

December 27, 2013

  • …have confidence that EqualsVerifier covers 100% of your equals and hashCode methods. (FAQ)
  • …specifically ignore certain fields using #allFieldsShouldBeUsedExcept(). (Issue 82)
  • …test classes that have an array field, but that don’t declare an equals method.
  • …get clearer error messages around abstract delegation. This clarifies especially classes that contain Joda-Time LocalDate fields.
  • …stop worrying about adding prefab values for BitSet. (Issue 86)

Version 1.3.1

June 9, 2013

  • …read error messages on the new EqualsVerifier website at, which matches EqualsVerifier’s fully qualified name: nl.jqno.equalsverifier.EqualsVerifier.
  • …disregard .debug(), as it is deprecated. Relevant exceptions are now included as a cause in the stack trace.
  • …test “versioned entity” classes where a zero id field indicates that the object is new, by suppressing Warning.IDENTICAL_COPY_FOR_VERSIONED_ENTITY. (Issue 80)
  • …get more accurate transitivity errors. (Issue 78)
  • …stop worrying about exceptions thrown in toString. (Issue 79)
  • …stop worrying about adding prefab values for UUID, to avoid that pesky recursion warning. (Issue 81)

Version 1.3

June 9, 2013

Please don’t use version 1.3; it’s a broken release. Use 1.3.1 instead.

Version 1.2

March 26, 2013

  • …get a transitivity error message for classes that use or in their equals method. (Issue 75; blog post about the problem and the solution)
  • …expect more robustness from EqualsVerifier when the toString method of the class under tests throws exceptions.
  • …use single value enums (and hence, singletons) in your classes, even if they don’t count for equals and hashCode. (Issue 74)
  • …use forRelaxedEqualExamples with classes containing null fields. (Issue 73)
  • …run EqualsVerifier’s test suite with less chance of false negatives. (Issue 77)
  • …build EqualsVerifier using Ant 1.9. (Issue 76)

Version 1.1.4

January 14, 2013

  • … fork EqualsVerifier on GitHub! EqualsVerifier has moved its code to GitHub. The project frontpage will remain at Google Code.
  • … use EqualsVerifier on a class whose superclasses have no declarations for equals and hashCode. (Issue 63)
  • … get an error when using #allFieldsShouldBeUsed() on a class that has fields but no declarations for equals and hashCode (and hence doesn’t use these fields). (Issue 67)
  • … get a more informative error message on Abstract Delegation errors: EqualsVerifier now also mentions the name of the abstract method that was called.

Version 1.1.3

April 21, 2012

  • … add static fields to your classes that are tested with #allFieldsShouldBeUsed(). EqualsVerifier will no longer complain if these static fields aren’t used in your equals and hashCode methods. (Issue 57)
  • … get a complaint from EqualsVerifier when your equals method works incorrectly if a field in the class under test is null. (Issue 59)

Version 1.1.2

March 1, 2012

  • … stop worrying about EqualsVerifier recursively changing the value of non-final static fields, causing other tests to fail. (Issue 55, Comment 8)

Version 1.1.1

February 21, 2012

  • … suppress Warning.IDENTICAL_COPY if you want to use reference equality in an overridden equals method. (Issue 56)

Version 1.1

February 11, 2012

  • … get a warning if you forgot to include a field in your equals or hashCode method, by calling the #allFieldsShouldBeUsed() method on EqualsVerifier. (Issue 53)
  • … get an error message if you include a reference-equality check (this == obj), followed by an incorrect instanceof check in your equals method. EqualsVerifier will now notice if you do an instanceof check for a class other than the one that you are testing. (Issue 55, Comment 2)
  • … stop worrying about EqualsVerifier changing the value of non-final static fields, causing other tests to fail. (Issue 52 and Issue 55)
  • … stop worrying about adding prefab values for File, List, Set, Map and Collection to avoid unjustified warning. (Issue 49 and Issue 51)

Version 1.0.2

August 14, 2011

  • … find EqualsVerifier in Maven Central! (Issue 36)
  • … get an error message when you forget to include an instanceof check or a getClass() check in your equals method. (Issue 47)
  • … use EqualsVerifier on a class whose superclass has abstract declarations for equals and hashCode. (Issue 48)

Version 1.0.1

April 17, 2011

  • … use EqualsVerifier on dynamically generated classes by disabling annotation processing. (Issue 41)
  • … use EqualsVerifier on classes that are a subclass of one of the classes from rt.jar, which are loaded by the system classloader. (Issue 43)
  • … use EqualsVerifier on classes with float or double fields but no equals method. (Issue 44)
  • … stop worrying about adding prefab values for Throwable and Exception, to avoid that pesky recursion warning. (Issue 45)

Version 1.0

February 23, 2011

  • … use the following annotations on your classes and fields: EqualsVerifier will know what to do!
    • @Immutable: EqualsVerifier will not complain about non-final fields if your class is @Immutable. (It doesn’t matter in which package the annotation is defined; javax.annotations.concurrent.Immutable, net.jcip.annotations.Immutable or your own implementation will all work fine.)
    • @Nonnull, @NonNull and @NotNull: EqualsVerifier will not check for potential NullPointerExceptions for any field marked with any of these annotations. (Again: the source package doesn’t matter.) This is similar to calling suppress(Warning.NULL_FIELDS), but on a per-field basis, instead of all-or-nothing. (Issue 28)
    • @Entity: EqualsVerifier will not complain about non-final fields if your class is a JPA Entity. Note that this only works for javax.persistence.Entity, not for Entity annotations from other packages. (Issue 37)
    • @Transient: Fields marked with this annotation (again, only from javax.persistence.Transient), will be treated the same as fields marked with Java’s transient modifier; i.e., EqualsVerifier will complain if they are used in the equals contract.
  • … see which field throws a potential NullPointerException, instead of having to guess which one it was. (Issue 39)
  • … be sure that EqualsVerifier doesn’t detect recursive data structures where there are none. (Issue 34)
  • … stop worrying about adding prefab values for BigDecimal and BigInteger, to avoid that pesky recursion warning. (Issue 34)

Version 0.7

November 15, 2010

  • … test equals methods that use a call to getClass(), instead of an instanceof check, to determine the type of the object passed in, by calling the #useGetClass() method on EqualsVerifier.
  • … get a warning when you use a transient field in your equals or hashCode method. Don’t worry; you can suppress this warning too.
  • … stop worrying about adding prefab values for certain Java API classes, like Date, GregorianCalendar, or Pattern, to avoid that pesky recursion warning.
  • … get a link to the Error messages page to get more help, when EqualsVerifier finds an error.
  • … enjoy many javadoc improvements (including the one in Issue 32).
  • Also, the back end is almost completely re-written.

Version 0.6.5

August 5, 2010

  • … use EqualsVerifier on classes with fields of a wide variety of Java API types, without getting ‘Recursive datastructure’ errors all the time. (Issue 30)
  • … get a more helpful error message when equals, hashCode or toString throws something other than a NullPointerException when one of the fields in null. (Issue 31)

Version 0.6.4

June 13, 2010

  • … get an appropriate error message when Arrays.hashCode() or Arrays.deepHashCode() should have been used, instead of a message that a certain field is used in equals but not in hashCode or the other way around. (Issue 27)
  • … get less frequent non-nullity errors on toString.

Version 0.6.3

May 18, 2010

  • … test the equals/hashCode contract for classes that don’t override equals or hashCode. (Issue 23)
  • … use EqualsVerifier in conjuction with the EclEmma code coverage tool. (Issue 22)
  • … test classes that contain (indirect) references to non-static inner classes, without getting messages about recursive data structures. (Issue 21)

Version 0.6.2

February 11, 2010

  • … use #withPrefabValues() for recursive data structure fields in superclasses again. (Issue 20)

Version 0.6.1

February 6, 2010

  • … use #withPrefabValues() for fields which delegate to abstract methods again. (Issue 14)
  • … access the #verify() method more quickly using autocompletion in IDEs. (The method #verbose() has been renamed to #debug().)

Version 0.6

January 30, 2010

  • … use a more consistent API. #with(Feature) is now #suppress(Warning), which feels more Java-y. Former features that were not warnings, are now proper methods on EqualsVerifier: #verbose() and #withRedefinedSuperclass().
  • … get better error messages:
    • many messages now span multiple lines for improved readability;
    • hashCodes are printed (where relevant);
    • unexpected exceptions are no longer eaten by EqualsVerifier, so they can be read without calling #verbose();
    • calls to abstract methods from within equals and hashCode, which cannot be resolved, are now detected and properly reported. (Issue 14)
  • … verify classes that contain fields whose equals methods might throw NullPointerExceptions. (Issue 19)
  • … be sure that EqualsVerifier doesn’t detect recursive data structures where there are none. (Issue 18)
  • … use fields of type Class in your classes. (Issue 17)

Version 0.5

September 1, 2009

  • … test classes that contain fields of interface or abstract class types (such as Lists, and other Collection types). (Issue 12)
  • … step through the source code in Eclipse after adding the EqualsVerifier jar to your project. (Issue 11)

Version 0.4

August 29, 2009

  • … verify equality rules that are more relaxed than simple field-by-field comparison. (Issue 9)

Version 0.3

August 1, 2009

  • … use EqualsVerifier without having to call #withPrefabValues(...) all the time. (Issue 7)

Version 0.2

July 3, 2009

  • … use the fields are never null feature on classes instantiated with #forClass(Class). (Issue 1)
  • … check if Arrays.deepEquals was used for multidimensional and Object arrays. (Issue 3)
  • … access optional features through a clean enum instead of through lots of different method calls. (Issue 4)
  • … use EqualsVerifier in unit test frameworks other than JUnit 4 (Issue 5)
  • … have stacktraces be printed to System.err. (Issue 6)

Version 0.1

June 1, 2009

  • … use EqualsVerifier!