Feature request: A modifier annotation for data classes to provide a non arg constructor on JVM

Language Design
4

You’re right!

Let me clarify my propose:

Using JPA, I can build immutable entities with data classes (using only val properties), see this:

https://github.com/lucasjobs/koltin-jpa-dataclass/blob/master/src/main/kotlin/model/Person.kt

This works very fine! See my entire demo on github.

Look that, although immutable and instantiated by a secondary private non arg constructor (calling the primary, providing imaginary values), JPA makes a magic trick and delivers me a beautiful entity with all correct values.

Even though, id is a val, JPA will save the correct value id on data base.

Sounds crazy but, this entity is immutable to me, is immutable to compiler, but isn’t immutable to JPA. (It’s a desired behavior.)

I’m assuming that JPA will never deliver me an entity inconsistent (i.e. with the default values provided by me), always reflecting all entity properties values to the correct ones.

My propose is:

  1. A modifier annotation generates an additional non arg constructor only in bytecode .class
  2. This constructor only can be called by reflection.
  3. When this constructor is called, they instantiate an object with all properties no initialized. (Kotlin lateinit principle). JPA don’t care about this.
  4. In this moment, if any property is accessed, it should throw a special exception that clearly identifies the property being accessed and the fact that it hasn’t been initialized. Like lateinit. We could say that in this particular moment, the object is in limbo.
  5. Who called this constructor (by reflection), either JPA or whatever, should be responsible to provide a value through reflection to every property before delivers the object. JPA already did this.

I just want to suppress the necessity of write a secondary private non arg constructor passing imaginary arguments to primary.

1 Like