Sometimes, implementing equals() and hashCode() using @Id is more convenient then using a business equivalence as outlined here [1] The most painful, well-known problem, with this approach, is that one can get into hard-to-debug situations when entities with null @Id get into collections and then get their @Id assigned by Hibernate later

My question is: When implementing equals()/hashCode using @Id, is it a good idea to have equals() and hashCode() throw runtime exception when value of @Id field is null?

[1] https://developer.jboss.org/wiki/EqualsandHashCode

You should not throw an exception in equals and hashCode. Check this article to learn how you can implement equals and hashCode based on the entity identifier in a safely manner.

I read the article and it is an interesting strategy. However. It will not be very performant in JDK collections as all your objects collide on that hashcode.

Why do you think it's wrong to throw an exception in equals and hashCode? The goal is to uncover situations where objects are put into collections without ID assigned. Because that is always a programming error no?

You are talking about general best practices. Unless you have millions of entries, you should be fine. If you have millions of entities, then fetching all those is going to be the performance bottleneck anyway.

Equals and hashCode don't need to throw exceptions. If you really want to spot some weird use case, you should probably log an error message, while still allowing the applications to proceed. The equals and hahsCode contract don't say that you should ever throw an Exception, so keep that in mind too. This question about having Exceptions thrown from equals has been asked on StackOverflow, so you should chek it out too.