dynamically deriving class from interface: I hav...

# reflect

[DALDEI]

dynamically deriving class from interface: I have a working code that can take a kotlin interface and constrct a 'bean' like object class using byte-buddy.
roughly: for every kotlin property it creates a java field, getter and setter (getXXX, setXXX) The result is then accessed as <java class just created>.kotlin and returned as a KClass
This works generally well except for this case: One use case is to create a mutable bean from a imutable interface, primarily for configuraiton injection. Example:
Kotlin:
interface A { val a : String }
byte-buddy: pseudo Java created:
class A_random implements A {
String a ;
String getA() { return a; }
void setA(String value) { a = value }
}

This also largely works unless I pass the resulting class to something that does java reflection / introspection
This produces the odd result of TWO properties named "a" -- Pseudo Kotlin from a helper function 'describe':

( from intellija kotlin REPL)

interface A { val a : String }
val b = concrete<A>()
b.describe()
-------------->>> RESULT
public open class java_1999567753 : Line_7.A {
public var a : kotlin.String!
public val a : kotlin.String
}

-------------------

I have verified other code 'sees' the same thing -- eg. Vaadin behaves as if there were two "a" properties sharing the same backing store

?Q: Is this something that is resolvable without resortign to creating kotlin Metadata ?

Context: My ultimate goal is to create a 'family ' of related classes but using only 1 definiton . e.g.
"Pristine Class" -- interface or class with read-only members
"DTO" class -> Class that can be populated with Jackson serialization/deserialization and sent 'over the wire"
"Client Class" -> Class that can be constructed by 'client' code in order to call an API , preferably in pieces (not all in constrtor)
"Server class" ->> Class 'server' recieves as a message
"Persistance Class" --> Class used to store data as a 'file' (JSON, Properties etc) and used to read later as part of a complex hierarchy.
"Java Friendly" class -- down to ugly reflection details -- such that it can be used in reflection -heavy frameworks
JSON Schema of said class --> used for both validation and creation of data entry forms on the fly

Im about 90% there in most cases ( and its fine if any or all of the above happen to be the 'same')
My 'goal' is a theory that one should NOT have to duplicate the definitions of the class (or rather its set of properties and defaults) in order to use such chass in the above scenarios.

This last bit threw me -- for a while I thought it was due to mix/match of var/val convusing kotlin burt no: this also has same problem:

interface B { var b : String }
val b = concrete<B>()
b.describe()
public open class java_847119339 : Line_12.B {
public var b : kotlin.String!
public var b : kotlin.String
}

I've tried variants such as making the gacking field private, omitting the getters/setters -- no go.
Latest theory is that its due to inheritance, possibly lacking the kotlin 'override'

Any suggestions on either how to 'fix' this or an alternate approach ?
My next step may be to try source generation instead of bytecode generation -- but that is more complex as it requires multi-pass compilation , annotation processing (same thing) or scripting (which I have working but its 'iffy' and slow given current implemention of kotlin scripting)