This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Having hashCode() and equals() in entities is almost always broken. There is only a single way to do this right, and this is by manually (upfront) generate an Id and set it _before_ the JPA provider would do. E.g. by using UUID or a manually managed sequence counter. ALL other ways are broken! I bet there is some arguing as the old lore of hashCode is still around. But in the meantime even Gavin says that it is a bad idea as the DB identity does not match the Java identity if we use @Id. Even if we let aside that managed entities must not be accessed from multiple Threads at the same time as per the JPA spec and thus they should not get stuffed into any Map, Set, etc at all in the first place...
Sorry, can you explain (1) what you see now that is wrong, i.e., show via code, not lots of words, and (2) what should be there instead, again in code. Not completely sure who the Gavin is you're referring to, either.
The Gavin I refer to is Gavin King, creator of Hibernate and founding JPA EG member. quote: "I think the basic fundamental misunderstanding here is that some people have decided (on the basis of what, I'm not sure) that Hibernate calls equals() and hashCode() on an entity object. It does not. Ever. (well, it does for classes with embedded composite ids, but it is trivial to avoid that by writing a composite identifier class) The only time that MyEntity.hashCode() gets called is if you, the user, add the entity to a HashSet. Now, that does include associations mapped with <set>, since Hibernate delegates to HashSet. But you could easily use <bag> instead, if this is such an enormous problem. FYI, I have written an entire large system using detached objects, w/o ever overriding equals() and hashCode(), but I would not now consider that to be a good practice." The same is true for JPA as well. Gavin said so for Hibernate and I can assure you the same for OpenJPA (being a committer). I don't know about Eclipselink, but if they need equals/hashCode, then they would break the spec. Thus NetBeans should *not* generate equals() and hashCode() at all. It's just bad and misleading style. http://wrschneider.blogspot.co.at/2012/01/equals-and-hashcode-on-entity-classes.html https://forum.hibernate.org/viewtopic.php?t=928172 https://community.jboss.org/wiki/EqualsAndHashCode
From quotation, I see no cons for equal/hashCode override, also part like "FYI, I have written an entire large system using detached objects, w/o ever overriding equals() and hashCode(), but I would not now consider that to be a good practice." in my opinion should be read as "it's possibe to not override but "but I would not now consider that to be a good practice". It's completely unclear what is wrong with generated equals/hashCode if hibernate never call it and will never fail because of these overridden methods, but some users may want to have these methods. Even as I see some people don't like it because of "bad style" and perfect realization is almost impossible, it doesn't look like a big issue if it's generated and is suitable in some cases. 10 pages of discussion on hibrnate.org means people are using these methods sometimes and are looking for some solutions. It may have sense to consider it as enhancement and add one more option into entities wizard to genrate/not equals/hashcode, default isn't clear to me yet.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss