[eclipselink-users] null handling for @Embeddable with EclipseLink 2.5.2

[Michael Hönnig <michael@xxxxxxxxxx>]

Hello EclipseLink experts,

We experienced some strange behaviour with EclipseLink 2.5.2 and 
@Embeddable/@Embedded when using change tracking with class weaving.

Let's say we have this @Embeddable:

@Embeddable
@SuppressWarnings("javadoc")
public class SomeEmbeddable {

    @Column
    private Long part1;

    @Column
    private String part2;

[...]
}

and an entity like this:

@Entity
public class SomeEntity {
    @Embedded
    private SomeEmbeddable embeddable;

    public void setEmbeddable(SomeEmbeddable newEmbeddable) {
        this.embeddable = newEmbeddable;
    }

[...]
}

now calling on a persistent entity: someEntity.setEmbeddable(null)

Thus assigning null to the @Embeddable field: no SET is generated for 
this change in the UPDATE SQL statement.
With @ChangeTracking(DEFERRED) (like without class weaving) the SQL is 
generated properly, though.

I searched the web for this and found several hints that null in 
@Embedded fields is actually not allowed.
E.g. here: 
https://en.wikibooks.org/wiki/Java_Persistence/Embeddables#Nulls
and here: https://java.net/jira/browse/JPA_SPEC-42

and here a similar problem:
https://www.eclipse.org/forums/index.php/t/474144/

Does anybody know where this behaviour is specified? I can't find in the 
JPA Specs that null is not allowed.

Even worse: When loading an @Embeddable with all values null, 
EclipseLink does not create in instance, but just sets the @Embedded 
field to null. Sounds like it's contradicting itself. I know, this 
behaviour can be changed using 
org.eclipse.persistence.mappings.AggregateObjectMapping.setIsNullAllowed() 
in a descriptor customizer.

Is it even allowed to exchange the whole @Embeddable instance? Or should 
the distinct fields be assigned to get proper change tracking with class 
weaving?

Another observation we made in this context:

For a while we needed to annotate the @Embeddable with 
@ChangeTracking(DEFERRED) because otherwise there was a memory leak. But 
that caused the same problem as mentioned above until we also applied 
the @ChangeTracking(DEFERRED) to the entity, then it worked again.

Are there any rules I should know about? Or is it simply a bug?

Thanks in advance
... Michael



--
http://michael.hoennig.de