{"id":115,"date":"2009-04-12T02:18:57","date_gmt":"2009-04-12T09:18:57","guid":{"rendered":"http:\/\/www.zulutown.com\/blog\/?p=115"},"modified":"2009-04-12T02:18:57","modified_gmt":"2009-04-12T09:18:57","slug":"hibernate-hashcode-equals-and-eclipse","status":"publish","type":"post","link":"http:\/\/www.zulutown.com\/blog\/2009\/04\/12\/hibernate-hashcode-equals-and-eclipse\/","title":{"rendered":"Hibernate, hashCode, equals and Eclipse"},"content":{"rendered":"

Java programmers use often Eclipse to write their code, and it’s common to rely on the Eclipse features to quickly generate the hashCode()<\/em> and equals(Object obj)<\/em> methods of the beans.<\/p>\n

Working on a Hibernate based application, I often noticed unexpected issues, and after some in depth<\/em> debugging I’ve found that probably some of these problems were caused by the Eclipse automatic generation of equals<\/code> method.<\/p>\n

In my opinion, this is mostly caused by the fact that Hibernate generates on top of our entity bean<\/em> classes other proxy classes<\/em> that overrides the getters, and other methods in order to provide the lazy loading<\/em> of data.<\/p>\n

I.e.: When Hibernate loads from the DB a Movie<\/code> bean, it will have, for example, an associated list of MovieActor<\/code> objects. Obviously Hibernate will not fetch all the data related to every single actor, but anyway it will generate the stub<\/em> for the MovieActor objects.<\/p>\n

The programmer would be tempted to use code like this:<\/p>\n

Movie aMovie = getEntityManager.find(...);\r\nMovieActor aMovieActor = getEntityManager.find(...);\r\nif (aMovie.getActors().contains(aMovieActor)) {\r\n\tSystem.out.println(aMovieActor.getActor().getName() + \" acted in the movie \" + aMovie.getTitle());\r\n}<\/pre>\n
I noticed that contains<\/code> method often returns false<\/code> even if that actor really acted in that movie!
\nAfter some long debugging sessions, my final idea is that the problem is how Eclipse automatically generated the equals<\/code> method of MovieActor<\/code> class:<\/p>\n
\t@Override\r\n\tpublic boolean equals(Object obj) {\r\n\t\tif (this == obj)\r\n\t\t\treturn true;\r\n\t\tif (obj == null)\r\n\t\t\treturn false;\r\n\t\tif (!(obj instanceof MovieActor))\r\n\t\t\treturn false;\r\n\t\tMovieActor other = (MovieActor) obj;\r\n\t\tif (id == null) {\r\n\t\t\tif (other.id != null)\r\n\t\t\t\treturn false;\r\n\t\t} else if (!id.equals(other.id))\r\n\t\t\treturn false;\r\n\t\treturn true;\r\n\t}<\/pre>\n
In this code id<\/code> is an @EmbeddedId<\/code> composed by the Actor and the Movie associations. What I believe that causes problems is: other.id<\/code><\/strong>!<\/p>\n
This is because probably the Id of the other<\/code> object hasn’t been loaded yet, and its fetching will happen on the calling of getId()<\/code> of the proxy class built on MovieActor.<\/p>\n
So, I changed the equals<\/code> method this way:<\/p>\n
\t@Override\r\n\tpublic boolean equals(Object obj) {\r\n\t\tif (this == obj)\r\n\t\t\treturn true;\r\n\t\tif (obj == null)\r\n\t\t\treturn false;\r\n\t\tif (!(obj instanceof MovieActor))\r\n\t\t\treturn false;\r\n\t\tMovieActor other = (MovieActor) obj;\r\n\t\tif (id == null) {\r\n\t\t\tif (other.getId() != null)\r\n\t\t\t\treturn false;\r\n\t\t} else if (!id.equals(other.getId()))\r\n\t\t\treturn false;\r\n\t\treturn true;\r\n\t}<\/pre>\n
And after this little change, contains<\/code> began to work correctly!<\/p>\n
Another very important<\/strong> thing is to check use ‘instanceof’ to compare types<\/em> otherwise some ugly code would be generated.
\nSome checks like if (getClass() != obj.getClass())<\/code> would miserably fail when hibernate proxy classes are used.<\/p>\n","protected":false},"excerpt":{"rendered":"
Java programmers use often Eclipse to write their code, and it’s common to rely on the Eclipse features to quickly generate the hashCode() and equals(Object obj) methods of the beans. Working on a Hibernate based application, I often noticed unexpected … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,118],"tags":[122,121,130,128,164,131,120,127,125,119,174,132,17,126,129,123,124],"_links":{"self":[{"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/posts\/115"}],"collection":[{"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/comments?post=115"}],"version-history":[{"count":2,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/posts\/115\/revisions"}],"predecessor-version":[{"id":117,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/posts\/115\/revisions\/117"}],"wp:attachment":[{"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/media?parent=115"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/categories?post=115"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.zulutown.com\/blog\/wp-json\/wp\/v2\/tags?post=115"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}