review fix: CtExecutableReference have all the same hashcode

[surli]

It seems that Spoon make no distinction between reference hashcode: they all have a value to 1.

[surli]

@monperrus is it a wanted behaviour? It seems particularly weird to me, especially because it prevents us in using properly collection of references.

[monperrus]

@monperrus is it a wanted behaviour?

Not really

because it prevents us in using properly collection of references.

I'd say it still works correctly, but inefficiently (many calls to equals)

[surli]

I'd say it still works correctly

Why "correctly"? here the test shows that two completely distinct executable references have the same hashcode...

[surli]

I propose a fix here, but I'm not sure it's enough: several elements in Spoon may have the same hashCode issue.

[monperrus]

Why "correctly"?

A hashCode is an approximation in essence. It's normal that you sometimes have collisions and the collection libraries know how to handle this. You have bad performance if you have too many collisions, but you have correct execution.

[monperrus]

This fix looks good to me.

[surli]

@monperrus it's ready for merging for me.

[surli]

The CI is ok: we have an issue with gakoci because Java 8 release 151 seems not available through maven docker image easily. If you're ok I propose that you merge this one as I need it for #1707