Yes, EclipseLink (default JPA provider) doesn't follow the specifications on this point.
I have tested your example and I got to the same output: the
Phone entity was persisted (!?!?). Instead the persistence provider should have thrown an
IllegalStateException, just like when you change line 15 of
EmployeeService into
em.persist(employee2);
If have reread the following part a couple of times and I am pretty sure they made a mistake implementing it:
If X is an entity merged to X', with a reference to another entity Y, where cascade=MERGE or cascade=ALL is not specified, then navigation of the same association from X' yields a reference to a managed object Y' with the same persistent identity as Y.
What is meant here (
well the specs are not clear, but that is how I understand it) is that if there is
no cascade specified that the only attribute that will be updated is the
foreign key column to Y in X. Changes to Y won't be merged, but changes in X with regard to the relationship of Y will be updated in the database.
Precondition here is that there is a row in the database reflecting Y.
Following your example:
and
When you run this you will see that the call to
service.merge(notManaged); will update the foreign key column
EMPLOYEE.PHONE_ID, but it won't change the
PHONE.PHONENUMBER.