Skip to content

kuri-bind: optional java.lang.reflect-native member scanner #42

Description

@OmarAlJarrah

kuri-bind uses Kotlin reflection (kotlin-reflect) as its single member-discovery mechanism. Java
POJOs and records are supported through Kotlin reflection's interop views (getters surface as member
functions, fields as member properties, record components in canonical order). That works, but it pulls
kotlin-reflect onto the classpath even for consumers whose request objects are plain Java.

A dedicated java.lang.reflect-native member scanner would let pure-Java consumers bind without
kotlin-reflect: read bean getters (getX/isX), fields, and record components directly. The
MemberScanner interface already exists as the seam — the binder engine is written against it, so a
second implementation (selected at runtime or via an option) is all that's required.

Open questions:

  • Selection: classpath probe for kotlin-reflect, an explicit option, or a separate artifact.
  • Whether annotation-site resolution (@get:/@field:/constructor parameter) can match kotlin-reflect
    fidelity for Kotlin classes without kotlin-reflect (likely limited — this backend targets Java shapes).

Filed to track demand, per the note in the README.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions