Deprecated API

Contents

• Interfaces
• Classes
• Methods

Interfaces

Interface	Description
org.assertj.core.api.iterable.Extractor	use Function instead

Classes

Class	Description
org.assertj.core.api.Java6Assertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. Assertions compatible with Android. Duplicated from Assertions.
org.assertj.core.api.Java6BDDAssertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. Android-compatible BDD-style assertions duplicated from BDDAssertions.
org.assertj.core.api.Java6BDDSoftAssertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. BDD-style Android-compatible soft assertions. Duplicated from BDDSoftAssertions.
org.assertj.core.api.Java6JUnitBDDSoftAssertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. Duplicate of JUnitBDDSoftAssertions compatible with Android.
org.assertj.core.api.Java6JUnitSoftAssertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. JUnitSoftAssertions rule compatible with Android. Duplicated from JUnitSoftAssertions.
org.assertj.core.api.Java6SoftAssertions	For Android compatible assertions use the latest assertj 2.x version which is based on Java 7 only. Soft assertions compatible with Android. Duplicated from SoftAssertions.
org.assertj.core.api.junit.jupiter.SoftlyExtension	This functionality (and more) has been rolled into SoftAssertionsExtension as of AssertJ 3.18.0.
org.assertj.core.api.JUnitJupiterBDDSoftAssertions	use SoftAssertionsExtension instead. Same as SoftAssertions, but with the following differences: First, it's a JUnit Jupiter extension, which can be used without having to call assertAll(), example: public class SoftlyTest { @RegisterExtension public final JUnitJupiterBDDSoftAssertions softly = new JUnitJupiterBDDSoftAssertions(); @Test public void soft_bdd_assertions() throws Exception { softly.then(1).isEqualTo(2); softly.then(Lists.newArrayList(1, 2)).containsOnly(1, 2); } } Second, the failures are recognized by IDE's (like IntelliJ IDEA) which open a comparison window.
org.assertj.core.api.JUnitJupiterSoftAssertions	use SoftAssertionsExtension instead. Same as SoftAssertions, but with the following differences: First, it's a JUnit Jupiter extension, which can be used without having to call assertAll(), example: public class SoftlyTest { @RegisterExtension public final JUnitJupiterSoftAssertions softly = new JUnitJupiterSoftAssertions(); @Test public void testSoftly() throws Exception { softly.assertThat(1).isEqualTo(2); softly.assertThat(Lists.newArrayList(1, 2)).containsOnly(1, 2); } } Second, the failures are recognized by IDE's (like IntelliJ IDEA) which open a comparison window.
org.assertj.core.api.recursive.comparison.FieldLocation	this class is meant to be internal and it is exposed only for backward compatibility together with RecursiveComparisonConfiguration.registerComparatorForField(Comparator, FieldLocation), it will be restricted to package-private visibility in the next major release.
org.assertj.core.error.AssertionErrorMessagesAggregrator	use AssertionErrorMessagesAggregator instead

Methods

Method	Description
org.assertj.core.api.AbstractAssert.equals(Object)	use AbstractAssert.isEqualTo(java.lang.Object) instead
org.assertj.core.api.AbstractBooleanArrayAssert.usingDefaultElementComparator()	Custom element Comparator is not supported for Boolean array comparison.
org.assertj.core.api.AbstractBooleanArrayAssert.usingElementComparator(Comparator<? super Boolean>)	Custom element Comparator is not supported for Boolean array comparison.
org.assertj.core.api.AbstractBooleanAssert.usingComparator(Comparator<? super Boolean>)	Custom Comparator is not supported for Boolean comparison.
org.assertj.core.api.AbstractCharSequenceAssert.isJavaBlank()	Use AbstractCharSequenceAssert.isBlank() instead.
org.assertj.core.api.AbstractCharSequenceAssert.isNotJavaBlank()	Use AbstractCharSequenceAssert.isNotBlank() instead.
org.assertj.core.api.AbstractCharSequenceAssert.isXmlEqualTo(CharSequence)	This assertion has some limitations, for example it does not handle tab vs space and would fail if elements are the same but in a different order. The recommended approach is XML Unit which is able to deal with these limitations and provides many more features like XPath support and schema validation. Original javadoc Verifies that the actual CharSequence is equal to the given XML CharSequence after both have been formatted the same way. Example: String expectedXml = "<rings>\n" + " <bearer>\n" + " <name>Frodo</name>\n" + " <ring>\n" + " <name>one ring</name>\n" + " <createdBy>Sauron</createdBy>\n" + " </ring>\n" + " </bearer>\n" + "</rings>"; // No matter how your xml string is formatted, isXmlEqualTo is able to compare it's content with another xml String. String oneLineXml = "<rings><bearer><name>Frodo</name><ring><name>one ring</name><createdBy>Sauron</createdBy></ring></bearer></rings>"; assertThat(oneLineXml).isXmlEqualTo(expectedXml); String xmlWithNewLine = "<rings>\n" + "<bearer> \n" + " <name>Frodo</name>\n" + " <ring>\n" + " <name>one ring</name>\n" + " <createdBy>Sauron</createdBy>\n" + " </ring>\n" + "</bearer>\n" + "</rings>"; assertThat(xmlWithNewLine).isXmlEqualTo(expectedXml); // You can compare it with oneLineXml assertThat(xmlWithNewLine).isXmlEqualTo(oneLineXml); // Tip : use isXmlEqualToContentOf assertion to compare your XML String with the content of an XML file : assertThat(oneLineXml).isXmlEqualToContentOf(new File("src/test/resources/formatted.xml"));
org.assertj.core.api.AbstractCharSequenceAssert.usingDefaultElementComparator()	Custom element Comparator is not supported for CharSequence comparison.
org.assertj.core.api.AbstractCharSequenceAssert.usingElementComparator(Comparator<? super Character>)	Custom element Comparator is not supported for CharSequence comparison.
org.assertj.core.api.AbstractClassAssert.hasFields(String...)	use AbstractClassAssert.hasPublicFields(String...) instead.
org.assertj.core.api.AbstractCompletableFutureAssert.hasFailed()	Combine isCompletedExceptionally with isNotCancelled instead: assertThat(future).isCompletedExceptionally() .isNotCancelled(); This assertion is deprecated to change the semantics of failed to correspond to CompletableFuture.get() failing. Original javadoc Verifies that the CompletableFuture has completed exceptionally but has not been cancelled, this assertion is equivalent to: assertThat(future).isCompletedExceptionally() .isNotCancelled(); Assertion will pass : CompletableFuture future = new CompletableFuture(); future.completeExceptionally(new RuntimeException()); assertThat(future).hasFailed(); Assertion will fail : CompletableFuture future = new CompletableFuture(); future.cancel(true); assertThat(future).hasFailed();
org.assertj.core.api.AbstractCompletableFutureAssert.hasFailedWithThrowableThat()	Although not 100% the same, consider using AbstractCompletableFutureAssert.failsWithin(Duration) or AbstractCompletableFutureAssert.failsWithin(long, TimeUnit) instead: CompletableFuture future = new CompletableFuture(); future.completeExceptionally(new RuntimeException("boom!")); assertThat(future).failsWithin(1, TimeUnit.SECONDS) .withThrowableOfType(RuntimeException.class) .withMessage("boom!"); This assertion is deprecated because it relies on AbstractCompletableFutureAssert.hasFailed() semantics which we want to move away from (they are not clear!) and to use failure semantics corresponding to CompletableFuture.get() failing. Original javadoc Verifies that the CompletableFuture has completed exceptionally and returns a Throwable assertion object allowing to check the Throwable that has caused the future to fail. Assertion will pass : CompletableFuture future = new CompletableFuture(); future.completeExceptionally(new RuntimeException("boom!")); assertThat(future).hasFailedWithThrowableThat().isInstanceOf(RuntimeException.class); .hasMessage("boom!"); Assertion will fail : CompletableFuture future = new CompletableFuture(); future.completeExceptionally(new RuntimeException()); assertThat(future).hasFailedWithThrowableThat().isInstanceOf(IllegalArgumentException.class);
org.assertj.core.api.AbstractCompletableFutureAssert.hasNotFailed()	Use matches with the following combination instead: assertThat(future).matches (f -> f.isNotCompletedExceptionally() || f.isCancelled()); This assertion is deprecated because its semantic is not obvious. Original javadoc Verifies that the CompletableFuture has not failed i.e: incomplete, completed or cancelled. This is different from AbstractCompletableFutureAssert.isNotCompletedExceptionally() as a cancelled future has not failed but is completed exceptionally. Assertion will pass : CompletableFuture future = new CompletableFuture(); future.cancel(true); assertThat(future).hasNotFailed(); Assertion will fail : CompletableFuture future = new CompletableFuture(); future.completeExceptionally(new RuntimeException()); assertThat(future).hasNotFailed();
org.assertj.core.api.AbstractDateAssert.isAfterOrEqualsTo(Date)	prefer calling AbstractDateAssert.isAfterOrEqualTo(Date)
org.assertj.core.api.AbstractDateAssert.isBeforeOrEqualsTo(Date)	prefer calling AbstractDateAssert.isBeforeOrEqualTo(Date)
org.assertj.core.api.AbstractDateAssert.isWithinDayOfMonth(int)	use AbstractDateAssert.hasDayOfMonth(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinDayOfWeek(int)	use AbstractDateAssert.hasDayOfWeek(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinHourOfDay(int)	use AbstractDateAssert.hasHourOfDay(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinMillisecond(int)	use AbstractDateAssert.hasMillisecond(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinMinute(int)	use AbstractDateAssert.hasMinute(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinMonth(int)	use AbstractDateAssert.hasMonth(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinSecond(int)	use AbstractDateAssert.hasSecond(int) instead.
org.assertj.core.api.AbstractDateAssert.isWithinYear(int)	use AbstractDateAssert.hasYear(int) instead.
org.assertj.core.api.AbstractFileAssert.hasContentEqualTo(File)	use AbstractFileAssert.hasSameTextualContentAs(File) instead
org.assertj.core.api.AbstractFileAssert.hasSameContentAs(File)	use AbstractFileAssert.hasSameTextualContentAs(File) instead. Verifies that the content of the actual File is equal to the content of the given one. The charset to use when reading the actual file can be provided with AbstractFileAssert.usingCharset(Charset) or AbstractFileAssert.usingCharset(String) prior to calling this method; if not, the platform's default charset (as returned by Charset.defaultCharset()) will be used. Examples: // use the default charset File xFile = Files.write(Paths.get("xfile.txt"), "The Truth Is Out There".getBytes()).toFile(); File xFileClone = Files.write(Paths.get("xfile-clone.txt"), "The Truth Is Out There".getBytes()).toFile(); File xFileFrench = Files.write(Paths.get("xfile-french.txt"), "La Vérité Est Ailleurs".getBytes()).toFile(); // use UTF-8 charset File xFileUTF8 = Files.write(Paths.get("xfile-clone.txt"), Arrays.asList("The Truth Is Out There"), StandardCharsets.UTF_8).toFile(); // The following assertion succeeds (default charset is used): assertThat(xFile).hasSameContentAs(xFileClone); // The following assertion succeeds (UTF-8 charset is used to read xFile): assertThat(xFileUTF8).usingCharset("UTF-8").hasSameContentAs(xFileClone); // The following assertion fails: assertThat(xFile).hasSameContentAs(xFileFrench);
org.assertj.core.api.AbstractInputStreamAssert.hasContentEqualTo(InputStream)	use AbstractInputStreamAssert.hasSameContentAs(InputStream) instead
org.assertj.core.api.AbstractIterableAssert.containsOnlyElementsOf(Iterable<? extends ELEMENT>)
org.assertj.core.api.AbstractIterableAssert.hasOnlyOneElementSatisfying(Consumer<? super ELEMENT>)	use AbstractIterableAssert.singleElement() instead
org.assertj.core.api.AbstractMapAssert.extracting(Object...)	use AbstractMapAssert.extractingByKeys(Object[]) instead
org.assertj.core.api.AbstractMapAssert.usingDefaultElementComparator()	Custom element Comparator is not supported for MapEntry comparison.
org.assertj.core.api.AbstractMapAssert.usingElementComparator(Comparator<? super Map.Entry<? extends K, ? extends V>>)	Custom element Comparator is not supported for MapEntry comparison.
org.assertj.core.api.AbstractObjectAssert.isEqualToComparingFieldByField(Object)	Use the recursive comparison by calling AbstractObjectAssert.usingRecursiveComparison(). This method is deprecated because it only compares the first level of fields while the recursive comparison traverses all fields recursively (only stopping at java types). For example suppose actual and expected are of type A which has the following structure: A |— B b | |— String s | |— C c | |— String s | |— Date d |— int i isEqualToComparingFieldByField will compare actual and expected A.b and A.i fields but not B fields (it calls B equals method instead comparing B fields). The recursive comparison on the other hand will introspect B fields and then C fields and will compare actual and expected respective fields values, that is: A.i, A.B.s, A.B.C.s and A.B.C.d. Concretely instead of writing: assertThat(actual).isEqualToComparingFieldByField(expected); You should write: assertThat(actual).usingRecursiveComparison() .isEqualTo(expected); Original javadoc Asserts that actual object is equal to the given object based on a property/field by property/field comparison (including inherited ones). This can be handy if equals implementation of objects to compare does not suit you. Note that comparison is not recursive, if one of the field is an Object, it will be compared to the other field using its equals method. If an object has a field and a property with the same name, the property value will be used over the field. Private fields are used in comparison but this can be disabled using Assertions.setAllowComparingPrivateFields(boolean), if disabled only accessible fields values are compared, accessible fields include directly accessible fields (e.g. public) or fields with an accessible getter. The objects to compare can be of different types but the properties/fields used in comparison must exist in both, for example if actual object has a name String field, it is expected the other object to also have one. Example: // equals not overridden in TolkienCharacter TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT); TolkienCharacter frodoClone = new TolkienCharacter("Frodo", 33, HOBBIT); // Fail as equals compares object references assertThat(frodo).isEqualTo(frodoClone); // frodo and frodoClone are equals when doing a field by field comparison. assertThat(frodo).isEqualToComparingFieldByField(frodoClone);
org.assertj.core.api.AbstractObjectAssert.isEqualToComparingFieldByFieldRecursively(Object)	Prefer calling AbstractObjectAssert.usingRecursiveComparison() for comparing objects field by field as it offers more flexibility, better reporting and an easier to use API. Asserts that the object under test (actual) is equal to the given object based on a recursive property/field by property/field comparison (including inherited ones). This can be useful if actual's equals implementation does not suit you. The recursive property/field comparison is not applied on fields having a custom equals implementation, i.e. the overridden equals method will be used instead of a field by field comparison. The recursive comparison handles cycles. By default floats are compared with a precision of 1.0E-6 and doubles with 1.0E-15. You can specify a custom comparator per (nested) fields or type with respectively usingComparatorForFields(Comparator, String...) and AbstractObjectAssert.usingComparatorForType(Comparator, Class). The objects to compare can be of different types but must have the same properties/fields. For example if actual object has a name String field, it is expected the other object to also have one. If an object has a field and a property with the same name, the property value will be used over the field. Example: public class Person { public String name; public double height; public Home home = new Home(); public Person bestFriend; // constructor with name and height omitted for brevity } public class Home { public Address address = new Address(); } public static class Address { public int number = 1; } Person jack = new Person("Jack", 1.80); jack.home.address.number = 123; Person jackClone = new Person("Jack", 1.80); jackClone.home.address.number = 123; // cycle are handled in comparison jack.bestFriend = jackClone; jackClone.bestFriend = jack; // will fail as equals compares object references assertThat(jack).isEqualTo(jackClone); // jack and jackClone are equals when doing a recursive field by field comparison assertThat(jack).isEqualToComparingFieldByFieldRecursively(jackClone); // any type/field can be compared with a a specific comparator. // let's change jack's height a little bit jack.height = 1.81; // assertion fails because of the height difference // (the default precision comparison for double is 1.0E-15) assertThat(jack).isEqualToComparingFieldByFieldRecursively(jackClone); // this succeeds because we allow a 0.5 tolerance on double assertThat(jack).usingComparatorForType(new DoubleComparator(0.5), Double.class) .isEqualToComparingFieldByFieldRecursively(jackClone); // you can set a comparator on specific fields (nested fields are supported) assertThat(jack).usingComparatorForFields(new DoubleComparator(0.5), "height") .isEqualToComparingFieldByFieldRecursively(jackClone);
org.assertj.core.api.AbstractObjectAssert.isEqualToComparingOnlyGivenFields(Object, String...)	Use the recursive comparison by calling AbstractObjectAssert.usingRecursiveComparison() and specify the fields to ignore. Warning: the recursive comparison does not provide a strictly equivalent feature, instead it provides several ways to ignore fields in the comparison by specifying fields to ignore, or fields by type or fields matching regexes. The idea being that it is best to compare as many fields as possible and only ignore the ones that are not relevant (for example generated ids). This method is deprecated because it only compares the first level of fields while the recursive comparison traverses all fields recursively (only stopping at java types). For example suppose actual and expected are of type A which has the following structure: A |— B b | |— String s | |— C c | |— String s | |— Date d |— int i isEqualToComparingOnlyGivenFields will compare actual and expected A.b and A.i fields but not B fields (it calls B equals method instead comparing B fields). The recursive comparison on the other hand will introspect B fields and then C fields and will compare actual and expected respective fields values, that is: A.i, A.B.s, A.B.C.s and A.B.C.d. Assuming actual has 4 fields f1, f2, f3, f4, instead of writing: assertThat(actual).isEqualToComparingOnlyGivenFields(expected, f1, f2); You should write: assertThat(actual).usingRecursiveComparison() .ignoringFields(f3, f4) .isEqualTo(expected); Original javadoc Asserts that the actual object is equal to the given one using a property/field by property/field comparison on the given properties/fields only (fields can be inherited fields or nested fields). This can be handy if equals implementation of objects to compare does not suit you. Note that comparison is not recursive, if one of the field is an Object, it will be compared to the other field using its equals method. If an object has a field and a property with the same name, the property value will be used over the field. Private fields are used in comparison but this can be disabled using Assertions.setAllowComparingPrivateFields(boolean), if disabled only accessible fields values are compared, accessible fields include directly accessible fields (e.g. public) or fields with an accessible getter. The objects to compare can be of different types but the properties/fields used in comparison must exist in both, for example if actual object has a name String field, it is expected the other object to also have one. Example: TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT); TolkienCharacter sam = new TolkienCharacter("Sam", 38, HOBBIT); // frodo and sam both are hobbits, so they are equals when comparing only race assertThat(frodo).isEqualToComparingOnlyGivenFields(sam, "race"); // OK // they are also equals when comparing only race name (nested field). assertThat(frodo).isEqualToComparingOnlyGivenFields(sam, "race.name"); // OK // ... but not when comparing both name and race assertThat(frodo).isEqualToComparingOnlyGivenFields(sam, "name", "race"); // FAIL
org.assertj.core.api.AbstractObjectAssert.isEqualToIgnoringGivenFields(Object, String...)	Use the recursive comparison by calling AbstractObjectAssert.usingRecursiveComparison() and chain with ignoringFields(String...). This method is deprecated because it only compares the first level of fields while the recursive comparison traverses all fields recursively (only stopping at java types). For example suppose actual and expected are of type A which has the following structure: A |— B b | |— String s | |— C c | |— String s | |— Date d |— int i isEqualToIgnoringGivenFields will compare actual and expected A.b and A.i fields but not B fields (it calls B equals method instead comparing B fields). The recursive comparison on the other hand will introspect B fields and then C fields and will compare actual and expected respective fields values, that is: A.i, A.B.s, A.B.C.s and A.B.C.d. Concretely instead of writing: assertThat(actual).isEqualToIgnoringGivenFields(expected, "i", "b.s"); You should write: assertThat(actual).usingRecursiveComparison() .ignoringFields("i", "b.s") .isEqualTo(expected); Note that the recursive comparison also allows to ignore fields by type or matching regexes. Original javadoc Asserts that the actual object is equal to the given one by comparing their properties/fields except for the given ones (inherited ones are taken into account). This can be handy if equals implementation of objects to compare does not suit you. Note that comparison is not recursive, if one of the property/field is an Object, it will be compared to the other field using its equals method. If an object has a field and a property with the same name, the property value will be used over the field. Private fields are used in comparison but this can be disabled using Assertions.setAllowComparingPrivateFields(boolean), if disabled only accessible fields values are compared, accessible fields include directly accessible fields (e.g. public) or fields with an accessible getter. The objects to compare can be of different types but the properties/fields used in comparison must exist in both, for example if actual object has a name String field, it is expected the other object to also have one. Example: TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT); TolkienCharacter sam = new TolkienCharacter("Sam", 38, HOBBIT); // frodo and sam are equals when ignoring name and age since the only remaining field is race which they share as HOBBIT. assertThat(frodo).isEqualToIgnoringGivenFields(sam, "name", "age"); // OK // ... but they are not equals if only age is ignored as their names differ. assertThat(frodo).isEqualToIgnoringGivenFields(sam, "age"); // FAIL
org.assertj.core.api.AbstractObjectAssert.isEqualToIgnoringNullFields(Object)	Use the recursive comparison by calling AbstractObjectAssert.usingRecursiveComparison() and chain with ignoringExpectedNullFields(). This method is deprecated because it only compares the first level of fields while the recursive comparison traverses all fields recursively (only stopping at java types). For example suppose actual and expected are of type A which has the following structure: A |— B b | |— String s | |— C c | |— String s | |— Date d |— int i isEqualToIgnoringNullFields will compare actual and expected A.b and A.i fields but not B fields (it calls B equals method instead comparing B fields). The recursive comparison on the other hand will introspect B fields and then C fields and will compare actual and expected respective fields values, that is: A.i, A.B.s, A.B.C.s and A.B.C.d. Concretely instead of writing: assertThat(actual).isEqualToIgnoringNullFields(expected); You should write: assertThat(actual).usingRecursiveComparison() .ignoringExpectedNullFields() .isEqualTo(expected); Note that the recursive comparison also allows to ignore actual's null fields with ignoringActualNullFields(). Original javadoc Asserts that the actual object is equal to the given one by comparing actual's properties/fields with other's not null properties/fields only (including inherited ones). It means that if an actual field is not null and the corresponding field in other is null, this field will be ignored in comparison, but the opposite will make assertion fail (null field in actual, not null in other) as the field is used in the performed comparison and the values differ. Note that comparison is not recursive, if one of the field is an Object, it will be compared to the other field using its equals method. If an object has a field and a property with the same name, the property value will be used over the field. Private fields are used in comparison but this can be disabled using Assertions.setAllowComparingPrivateFields(boolean), if disabled only accessible fields values are compared, accessible fields include directly accessible fields (e.g. public) or fields with an accessible getter. The objects to compare can be of different types but the properties/fields used in comparison must exist in both, for example if actual object has a name String field, it is expected other object to also have one. Example: TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT); TolkienCharacter mysteriousHobbit = new TolkienCharacter(null, 33, HOBBIT); // Null fields in other/expected object are ignored, the mysteriousHobbit has null name thus name is ignored assertThat(frodo).isEqualToIgnoringNullFields(mysteriousHobbit); // OK // ... but this is not reversible ! assertThat(mysteriousHobbit).isEqualToIgnoringNullFields(frodo); // FAIL
org.assertj.core.api.AbstractPathAssert.hasSameContentAs(Path)	use AbstractPathAssert.hasSameTextualContentAs(Path) instead Verifies that the content of the actual Path is the same as the given one (both paths must be a readable files). The charset to use when reading the actual path can be provided with AbstractPathAssert.usingCharset(Charset) or AbstractPathAssert.usingCharset(String) prior to calling this method; if not, the platform's default charset (as returned by Charset.defaultCharset()) will be used. Examples: // use the default charset Path xFile = Files.write(Paths.get("xfile.txt"), "The Truth Is Out There".getBytes()); Path xFileUTF8 = Files.write(Paths.get("xfile-clone.txt"), "The Truth Is Out There".getBytes("UTF-8")); Path xFileClone = Files.write(Paths.get("xfile-clone.txt"), "The Truth Is Out There".getBytes()); Path xFileFrench = Files.write(Paths.get("xfile-french.txt"), "La Vérité Est Ailleurs".getBytes()); // The following assertion succeeds (default charset is used): assertThat(xFile).hasSameContentAs(xFileClone); // The following assertion succeeds (UTF-8 charset is used to read xFile): assertThat(xFileUTF8).usingCharset("UTF-8").hasContent(xFileClone); // The following assertion fails: assertThat(xFile).hasSameContentAs(xFileFrench);
org.assertj.core.api.Assert.equals(Object)	Throws UnsupportedOperationException if called. It is easy to accidentally call equals(Object) instead of Assert.isEqualTo(Object).
org.assertj.core.api.AtomicBooleanAssert.usingComparator(Comparator<? super AtomicBoolean>)	Custom Comparator is not supported for Boolean comparison.
org.assertj.core.api.ObjectEnumerableAssert.containsOnlyElementsOf(Iterable<? extends ELEMENT>)
org.assertj.core.api.recursive.comparison.FieldLocation.fielLocation(String)	use FieldLocation.fieldLocation(java.lang.String) instead
org.assertj.core.api.recursive.comparison.RecursiveComparisonConfiguration.registerComparatorForField(Comparator<?>, FieldLocation)	Since 3.17.0 use RecursiveComparisonConfiguration.registerComparatorForFields(Comparator, String...) instead.
org.assertj.core.util.Files.delete(File)	use https://commons.apache.org/proper/commons-io/javadocs/api-release/org/apache/commons/io/FileUtils.html#forceDelete-java.io.File- instead
org.assertj.core.util.Files.temporaryFolder()	Use either TempDir or TemporaryFolder
org.assertj.core.util.Maps.format(Map<?, ?>)	use StandardRepresentation.toStringOf(Map) instead.
org.assertj.core.util.Objects.areEqual(Object, Object)	Use Objects.deepEquals(Object, Object) instead.
org.assertj.core.util.Objects.areEqualArrays(Object, Object)	Use either Objects.deepEquals(Object, Object) or Arrays.deepEquals(Object[], Object[]).
org.assertj.core.util.Preconditions.checkNotNull(T)	use Objects.requireNonNull(Object) instead.