Generator-jhipster: Accept subclasses as parameter to equals() method in entities

[pblanchardie]

Overview of the feature request

I ran into issues with the current equals() implementation returning false with a Hibernate proxy.

As IntelliJ says, it's better to accept subclasses in this case.

Motivation for or Use Case

Avoid issues with Hibernate proxies of entities.

Related issues or PR

5604

• [x] Checking this box is mandatory (this is just to show you read everything)

[deepu105]

I have no idea what you are talking about. Please follow our guidelines. If you know its an issue please do a PR to fix it else provide all info required in guidelines

This ticket has been closed as the guidelines are not followed.

Tickets must follow our Guidelines, as mentioned in:

1. our Readme file on the front page of the project,
2. the "create a new ticket" page and
3. our Help page

We have also created a template on the "create a new ticket" page to help you follow those guidelines.

If this is indeed a JHipster bug, please open a new issue with proper details or update this issue with all details and request to reopen.
Issues opened without proper details will be closed without explanation.

If you have a question please use Stack Overflow, and tag the question with jhipster. This helps the project to keep the issue tracker clean. Also, Stack Overflow will give your question a larger audience:

• This will increase your chances to get an answer
• Answers will be of higher quality, as there is a voting system
• This will also help other users who might have the same issue, as questions are tagged and easily searchable

[pblanchardie]

I followed the guidelines for feature requests, perhaps it's not clear enough that I'm talking about the Entity.equals() method that is not valid from my point of view. I'll create later.

[Abdull]

@jdubois, has this ticket really been solved in 5.6.0? I noticed that 5.7.0 still generates problematic entity equals() methods.

In 5.7.0, an entity's equals() method still looks like this:

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || getClass() != o.getClass()) {
            return false;
        }
        SurveyProgram surveyProgram = (SurveyProgram) o;
        if (surveyProgram.getId() == null || getId() == null) {
            return false;
        }
        return Objects.equals(getId(), surveyProgram.getId());
    }

This equals implementation is problematic due to Javassist/Hibernate proxying, e.g. the following test will fail:

    @Test
    public void testWorkListSurveyProgramMapping() {
        WorkList underTestWorkList = workListRepository.getOne(5L);
        SurveyProgram expectedSurveyProgram = surveyProgramRepository.getOne(1L);
        SurveyProgram actualSurveyProgram = underTestWorkList.getSurveyProgram();
        LOG.info("expectedSurveyProgram.getClass()={}", expectedSurveyProgram.getClass());
        LOG.info("actualSurveyProgram.getClass()={}", actualSurveyProgram.getClass());
        assertEquals(expectedSurveyProgram, actualSurveyProgram);
        assertEquals(actualSurveyProgram, expectedSurveyProgram);
    }

Relevant Log output:

2018-11-21 18:48:30.226  INFO 8440 --- [           main] o.f.WorkListRepositoryIntTest        : expectedSurveyProgram.getClass()=class org.foo.SurveyProgram_$$_jvstef9_0
2018-11-21 18:48:30.226  INFO 8440 --- [           main] o.g.o.r.WorkListRepositoryIntTest        : actualSurveyProgram.getClass()=class org.foo.SurveyProgram_$$_jvstef9_0

Inspired by https://stackoverflow.com/a/18251818/923560, a working equals method would be:

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }
        if (o == null || !getClass().isAssignableFrom(o.getClass())) {
            return false;
        }
        SurveyProgram surveyProgram = (SurveyProgram) o;
        if (surveyProgram.getId() == null || getId() == null) {
            return false;
        }
        return Objects.equals(getId(), surveyProgram.getId());
    }

[ruddell]

@Abdull I don't see a linked pull request, so I don't think any changes were made. Closed tickets are automatically added to the milestone when a release is made.

The ticket was unclear (at least to me) as to what it was asking for, I didn't really understand it until you posted. A pull request would be appreciated.

[anthonyrichir]

Sorry to comment on this closed ticket but was this implementation of hashCode really expected in generators/entity-server/templates/src/main/java/package/domain/Entity.java.ejs ? It doesn't seem correct to me.

@Override
public int hashCode() {
    return 31;
}

[AdrienHorgnies]

https://github.com/jhipster/generator-jhipster/pull/9022/files#diff-ca3656a24e3d57448ef6ce13309f2c1dR451 doesn't seem right to me either. Was this intended ?

[jdubois]

@anthonyrichir yes, have a look at the blog post referenced when this was added. I agree it's strange, and I was quite suspicious at first!!

[jdubois]

@AdrienHorgnies yes this was intended, have a look at the blog post to which the change is referred