Skip to content

Metamodel processors: the Java processor is non-incremental with weak error reporting, and KSP diverges from APT #411

Description

@zantvoort

Java processor quality (storm-metamodel-processor):

  • No META-INF/gradle/incremental.annotation.processors descriptor, @SupportedAnnotationTypes("*") (MetamodelProcessor.java:66), and iteration over roundEnv.getRootElements() (:281) instead of getElementsAnnotatedWith. Gradle falls back to full recompilation of the source set on every change. The KSP side is correct (MetamodelProcessor.kt:1191-1192).
  • Error handling at :300-303 catches Exception with no Element argument (no IDE source location), no stack trace, and continues; KSP passes the declaration, includes the trace, and rethrows. Align on the KSP semantics.

APT/KSP divergence that breaks Java-to-Kotlin ports:

  • KSP emits an XNullableMetamodel per class and selects children by nullability (.kt:1285, :790); APT does not, so Owner_.address has a different static type per language.
  • KSP sources components from getAllProperties() (.kt:229), which includes body-declared and inherited properties: a val display: String get() = ... gets a metamodel field pointing at a nonexistent column. APT is structurally immune because it resolves through the canonical constructor.
  • KSP escapes Kotlin keywords at only one of five emission sites (.kt:1323): a property named with backticks (e.g. `object`) emits code that does not compile.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions