time to test equals() and hashCode() depends exponentially on the number of fields

[36893488147419103231]

In the project
https://github.com/36893488147419103231/pojo-tester-tester
in the package testertester.equalshashcode there are tests of 3 classes:

public class Small {
  int a,b,c
}
public class Medium {
  int a,b,c,d, e,f,g,h, i,j,k,l, m,n,o,p ,q,r,s,t, u;
}
public class Big {
  int a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
}

with equals() and hashCode() generated by IDE.

The first class is tested in no time, the second one takes about a minute, and the test for the third one did not terminate for me (but probably it would in about half an hour, unless it would take too much memory). UPD: bigTest failed after 8m 49s with java.lang.OutOfMemoryError: GC overhead limit exceeded.

It is important to test equals() and hashCode() in linear time.

I propose the following algorithm:

Start with 3 POJO objects, one filled with nulls (zeroes, etc.), and two others filled with values that do not repeat (well, it is difficult to find 20 different boolean values).
Initially for the class MyPojo {int a,b,c,d;}we have:

null, null, null, null
P,Q,R,S
W,X,Y,Z

On the first iteration, we will compare P, null, null, null with:

null, null, null, null
P, null, null, null
W, null, null, null

On the second iteration, we will compare P, Q, null, null with:

P, null, null, null
P, Q, null, null
P, X, null, null

On the 3rd iteration, we will compare P, Q, R, null with:

P, Q, null, null
P, Q, R, null
P, Q, Y, null

and so on.
Of course, you must check that a.equals(b) == b.equals(a), and that objects that are equal have equal hash codes.
You may check that the number of different returned hash codes is at least a half of the the number of objects that participated in comparisons.
I'd recommend performing additional comparisons on each iteration, e.g. that a.equals(null) == false, that a.equals(a) is true, and that a.equals(1) is false.

Note. This issue may be related on unrelated to #201

(UPDATE) Note 2. I believe, it is FieldUtils.permutations() called from ObjectGenerator.generateDifferentObjects() that is responsible for exponential growth. It for N fields, it returns 2^N permutations. If it returned a list of size N, consumption of both time and memory would be linear.

[36893488147419103231]

I have added a patch to the same https://github.com/36893488147419103231/pojo-tester-tester project.
Basically, after

  @BeforeClass
  public static void init() {
    LinearPatch.patch();
  }

Method.EQUALS and Method.HASH_CODE start to use N sequences of N fields instead of 2^N permutations of N fields.
As a separate project, it is a rather dirty hack; you are welcome to integrate it as, say, Method.EQUALS_FAST and Method.HASH_CODE_FAST (I could not extend a enum; by the way, this likely means that Method should not be a enum).

Strictly speaking, it is quadratic rather than linear, but it is not that much important.

[36893488147419103231]

see pull requests

[sta-szek]

I will try to make review on Friday, thanks for contributions!