Closing this as it is now implemented for embeddables, and implementing it for entities is questionable

Regarding @Immutable, yes I should have been more clear - I mean at the class level.

Regarding arg order... the problem we want to avoid is having to create a second array that acts as a "bridge" between Hibernate's internal state and what the ctor expects. Long term the best option would be to have Hibernate handle this during bootstrap and internally order its expectation for the attributes. This is obviously all a lot to tackle..

if you supply -parameters in java 8 they are named and you can line them up without regard to argument order.

I like the annotation Immutable - At the class level

For reasons I've already stated I do not like the phrase "value type" here. As Java moves to version 10 and beyond, "value type" will come to be synonymous with that Java 10 feature, which has an incorrect connotation with what we are describing here. I'm ok with some way of making this explicit (in fact I think its should only be explicit), just not the term.

I actually think our existing @Immutable fits well here. If a composite class is defined as immutable that would trigger this behavior - the expectation being that it would have a full constructor[1] and possibly we would check for final fields. Those expectations not being met would be an exception.

[1] You wont like this part, but there would also need to be a set order to the arguments in the constructor - an order that is defined by Hibernate. This comes down to arrays and how Hibernate handles "disassembled"/"dehydrated" state

It was suggested that there could/should be an annotation specifically used to remove abiguity. Like, `@ValueType` or something

re: above - yes, combined they don't make sense.