An IdClass is typically used for calling EM.find() on entities with compound identities, and are typically discarded once that fetch has been effected, so for most uses, they are probably treated as a read-only object after initialization. That usage fits the Record type quite well, so I think we should consider supporting Records annotated with @IdClass.
While it may make for convenient coding, I think this will help a lot with users writing correct IdClass implementations. Over the many years I've supported clients, one frequent mistake I've seen are clients who write IdClass types with faulty implementations of the equals() and hashCode(), which can lead to a lot of unpredictable behavior with implementations that actually use the IdClass implementation as an internal key in the persistence context. The fact that the compiler will create the equals() and hashCode() methods for the application developer would help a lot in reducing these sort of mistakes.
Since Records are essentially Java classes generated by the compiler, this should already be supported, but it would be good to update the documentation and bless this usage, as well as perhaps include it as an example in the spec doc, in order to encourage its use.
An IdClass is typically used for calling EM.find() on entities with compound identities, and are typically discarded once that fetch has been effected, so for most uses, they are probably treated as a read-only object after initialization. That usage fits the Record type quite well, so I think we should consider supporting Records annotated with
@IdClass
.While it may make for convenient coding, I think this will help a lot with users writing correct IdClass implementations. Over the many years I've supported clients, one frequent mistake I've seen are clients who write IdClass types with faulty implementations of the
equals()
andhashCode()
, which can lead to a lot of unpredictable behavior with implementations that actually use the IdClass implementation as an internal key in the persistence context. The fact that the compiler will create theequals()
andhashCode()
methods for the application developer would help a lot in reducing these sort of mistakes.Since Records are essentially Java classes generated by the compiler, this should already be supported, but it would be good to update the documentation and bless this usage, as well as perhaps include it as an example in the spec doc, in order to encourage its use.