This access strategy would enable use cases like:
enforcing class invariants through the constructor,
immutable fields or classes (all fields) and
support for Java 10 value types which are planned to be immutable.
Parameter names (introduced in Java 8) could be used to fulfill this goal.
Constructor would be used for writing entity state and for reading entity state accessors could be used.
To simplify the initial implementation following requirements might be added:
constructor access strategy can not be applied to classes that are to be proxied (for example in lazy loading scenarios)
only one constructor should be specified (for more complex use cases static factory methods can be suggested)
nothing to do with "lazy-loading as implemented in hibernate now is problematic". It's simply that the 2 concepts make zero sense combined.
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.
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 and possibly we would check for final fields. Those expectations not being met would be an exception.
 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
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
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..