Add default recursive comparison configuration for non accessible classes and fields

[Meijuh]

Add default recursive comparison configuration for non accessible classes and fields

[joel-costigliola]

At this moment I do not think AssertJ supports non-accessible classes and fields with Java 17+.

We know AssertJ can't introspect Java base types so it compares them with equals, this is not unreasonable since at some point you have to compare something.

Here are a couple ways of getting around your problem

• select the fields to compare with comparingOnlyFields or comparingOnlyFieldsOfTypes
• registering a bi-predicate to compare certain fields or types

Would that help ?

There is also the option of adding specific logic to certain type, for example the recursive comparison does not introspect Optional but simply get their values and compare them. If that makes sense for other java types we could do that.

[Meijuh]

Would that help ?

That would solve my problem, but:

• I would have to always look into the deep insides of code I may know nothing about,
• do this whenever I write a recursive comparison.

Maybe my example above is not perfect. In a production example I get the following errors if I include comparing ReentrantReadWriteLock.class:

field/property 'httpClient.cookieStore.lock' differ:
- actual value  : java.util.concurrent.locks.ReentrantReadWriteLock@7c88d04f[Write locks = 0, Read locks = 0]
- expected value: java.util.concurrent.locks.ReentrantReadWriteLock@71df5f30[Write locks = 0, Read locks = 0]

I guess above happens due to #2450, which will always give me a false positive?

Another example of a field I can not access:

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.util.concurrent.locks.Condition java.util.concurrent.ThreadPoolExecutor.termination accessible: module java.base does not "opens java.util.concurrent" to unnamed module @53ce1329

Above two errors gives me reason to believe I will not be able to do a full equivalence check anyway. So might as well ignore fields of particular types always.

So my suggestion is .ignoreNonExportedPackages() should always contain packages with such classes, instead of writing comparingOnlyFields or comparingOnlyFieldsOfTypes in all my assertions and in all my code bases.

[joel-costigliola]

I'm not opposed to the principle of having ignoreNonExportedPackages although I don't think there are so many problematic types, most of them would have an overridden equals.

What might be unclear for users is the content of all these non exported packages, would there be cases where is makes sense to compare them with their equals method ?

I'm happy to get a contribution on this one if you feel like it.

[joel-costigliola]

@Meijuh do you have a clear definition of "non exported" packages?
I'm asking for two reasons, first to guide the implementation (is there is an obvious way to detect that) and the documentation

[joel-costigliola]

I'm leaning towards adding two options to the recursive comparison:

• ignoringTypesMatchingRegexes(string... regexes) so that one can discard a bunch of types in packages
• usingEqualsForTypesMatchingRegexes(string... regexes) similar to the previous but instead of ignoring we would use equals to compare these values

[joel-costigliola]

I have added ignoringFieldsOfTypesMatchingRegexes(String... regexes) but not yet ignoringFieldsOfTypesMatchingRegexes since I think the case we are trying to solve is for java types that can't be introspected and the recursive comparison already uses equals for them.