What it can’t possibly be is a global setting. A MonetaryAmount with all null fields is never a meaningful monetary value no matter what “global” characteristics your program has. And indeed it seems to me that the default behavior is always better and more correct for at least the majority of embeddable classes in a program

I suppose it makes sense. We’d need an alternative before we remove the global setting though, because people do rely on this feature.

I mean, TBH, I really struggle to come up with even a single legit usecase for a class with everything null, and nobody so far has ever been able to show me one. For every concrete example I can think of, the default behavior is more correct. Perhaps you have a convincing example that would help me understand the motivation for this? I admit that I sometimes fall short on imagination. Even if you can think of an couple of great motivating cases, I still insist that such cases will always be exceptional cases in every program.

I’ve seen business applications where embeddables where used to group together information within an entity that have a common theme. So let’s say in a Customer entity you’d have a ShippingSection, a LegalSection, etc. All those sections being, well, just ways to group information together in a more manageable fashion than just dropping everything at the root of the entity. And that structure does help developers when manipulating the entity throughout the application, especially when the IDE auto-completes your calls to getters.

In that situation, a null “section” simply doesn’t make sense, and more importantly, it’s just inconvenient. You would have to check for nullness every time you call getShippingSection().setAddress("foo"), and manually set the embeddable to a non-null value. Or you’d have to write your getters in such a way that they automatically detect null embeddeds and initialize them with non-empty values.

Sure, in some cases those “sections” could be separate entities with a @OneToOne association, but in the cases I encountered, that had to practical benefit and implied a slightly more complicated DB schema, so we decided against it.