My two cents worth... I don't think the spec indicates that the @PostLoad should get fired on a merge() operation. I do agree that if the merge() operation requires loading from the database, then the @PostLoad should get fired. But, I don't see in the spec where it says that the merge() operation demands a load from the database (and thus the @PostLoad).
Section 188.8.131.52 states:
"If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance X'
of the same identity or a new managed copy X' of X is created."
Since OpenJPA utilizes a "detached state manager", that would constitute a pre-existing managed entity instance and there would be no requirement to go to the database. If you think about it, this would be a good thing to avoid extra, unnecessary trips to the database.
Now, if your detached entity does not use a "detached state manger" , then we probably have to go to the database (like the other providers) to load up the current state into a new managed copy and then merge in the updated values. From side conversations with Rick, this processing may not be working quite right, but that's how I am reading the spec and the scenario described here.
The other interesting piece from 184.108.40.206 is this:
"Any Version columns used by the entity must be checked by the persistence runtime implementation
during the merge operation and/or at flush or commit time. In the absence of Version columns there is
no additional version checking done by the persistence provider runtime during the merge operation."
Earlier comments by Rick seemed to indicate that the absence of an @Version field would be a reason to access the database during merge(). This paragraph seems to indicate that this version checking should not be done during merge()...
This looks to be a good problem. I think we have an issue or two to resolve here. We just need to come to a consensus.