UriTemplateRequestEntity doesn't override hashCode() and equals()

[abryantsev]

Affects: 5.3.8

---

Hi developers!

To fix a memory leak caused by the micrometer metrics used in the RestTemplate I need to switch to the usage of the uri template to build a RequestEntity instance. To test the produced instance from one of the internal implementation in my project I use assertThat from the Asserj library.

The problem is that the test is failing because of the not overridden equals() method in the UriTemplateRequestEntity class that is used internally by the Assertj. In fact both calls - equals() and hashCode() throws an exception on the instances of the UriTemplateRequestEntity that should never be the case if the instance of the latter is built correctly.

The following test fails because of the mentioned issue.

    @Test
    void test() {
        final Map<String, Object> vars = new HashMap<>();
        vars.put("id", 1);

        final RequestEntity<Void> requestEntity1 =
            RequestEntity.method(HttpMethod.GET, "http://test.api/path/{id}", vars).build();

        final RequestEntity<Void> requestEntity2 =
            RequestEntity.method(HttpMethod.GET, "http://test.api/path/{id}", vars).build();

        org.assertj.core.api.Assertions.assertThat(requestEntity1)
            .isEqualTo(requestEntity2);
    }

with the following stack trace

java.lang.UnsupportedOperationException
	at org.springframework.http.RequestEntity.getUrl(RequestEntity.java:165)
	at org.springframework.http.RequestEntity.equals(RequestEntity.java:198)
	at java.base/java.util.Arrays.deepEquals0(Arrays.java:4654)
	at java.base/java.util.Objects.deepEquals(Objects.java:90)
	at org.assertj.core.internal.StandardComparisonStrategy.areEqual(StandardComparisonStrategy.java:77)
	at org.assertj.core.internal.Objects.areEqual(Objects.java:361)
	at org.assertj.core.internal.Objects.assertEqual(Objects.java:337)
	at org.assertj.core.api.AbstractAssert.isEqualTo(AbstractAssert.java:359)

Could you please have a look? To workaround this issue I need to implement a very cumbersome test accessing internal fields one by one.

[sbrannen]

Good catch, @abryantsev.

Thanks for opening your first issue for the Spring Framework! 👍

We'll get this fixed in 5.3.11.

[nytro77]

@jhoeller Seems this fix violates the hashCode contract?
Two RequestEntity with the same uriTemplate but with different uriVarsArray and/or uriVarsMap are not equal, but the hashCode function will return the same value as that only takes uriTemplate into account?

EDIT: Sorry my bad. It seems that is OK after all. I just never had a reason to do so, but i do not doubt that you have :)

If two objects are unequal according to the equals(java.lang.Object) method, calling the hashCode method on each of the two objects doesn't need to produce distinct integer results. However, developers should be aware that producing distinct integer results for unequal objects improves the performance of hash tables

[jhoeller]

Well spotted, that's a tradeoff we make in quite a few classes: hashCode doesn't need to be as specific as equals, it is sufficient to only take core attributes into account there. In particular in case of competing/alternate attributes such as the uriVars variants here, we tend to simply omit them from hashCode.

Thanks for reviewing the change, in any case :-)