This seems to happen in combination with {code:java}

@DynamicUpdate
@OptimisticLocking(type = OptimisticLockType.DIRTY)

{code}

This i found by debugging:

In our case {{writtenFieldNames}} and writtenValues only contains the changed field and its new data as single entries, but the changed field is found in the attributeMapping on a bigger index. Then, this bigger index is used to access writtenValues. The misconception in this code here is that {{writtenFieldNames}}, writtenValues and the attributeMapping are of the same size and order, which they are not.

I am not sure why this goes away when disabling dynamic update and optimistic locking.