Skip to content

CONCEPT Cited by 1 source

Metaprogramming on broken code

Definition

Metaprogramming on broken code is the practice of using AST-level tooling that can parse, analyse, and rewrite source that does not currently compile. The distinguishing trait: the tool doesn't depend on a working type-checker / build — so it works during migrations, before fixes land, and across partially-translated files.

Why it matters

Most language-level metaprogramming tools are compiler plugins — they hook into a compiler's pipeline after attribution, which requires a valid type system and a buildable module. That's a non-starter for large migrations: the intermediate state of a Java→Kotlin conversion, or any multi-file refactor, is routinely unbuildable by construction.

The alternative is to build on a PSI-style (Program Structure Interface) layer — an AST + symbol-resolution library that operates independently of the compiler's type checker. PSI tools degrade gracefully: they resolve what they can, bail on what they can't, and don't require a green build to run.

Canonical wiki instance — Meta's Editus tool on PSI

Meta's internal Editus tool is built on JetBrains' PSI libraries for both Java and Kotlin. The 2024-12-18 Meta post makes the distinction sharp:

"Unlike most metaprogramming tools, it is very much not a compiler plugin, so it can analyze broken code across both languages, and does so very quickly. This is especially helpful for postprocessing because it's often running on code with compilation errors, doing analysis that requires type information. Some postprocessing steps that deal with dependents may need to resolve symbols across several thousand unbuildable Java and Kotlin files."

Concrete load-bearing example: a Kotlinator postprocessing step that translates Java interfaces scans the interface's Kotlin implementers — which themselves may be mid- conversion and not yet compiling — and rewrites override fun getName() → override val name for get-to-property migrations.

Limitations Meta calls out

The trade-off is precision: PSI-based symbol resolution is less precise than J2K's, "especially when symbols are defined in third-party libraries." Meta's tool "bails quickly and obviously" when it can't be confident — the resulting Kotlin may not build, but the required fix is usually obvious to a human. Meta's long-term plan is to port postprocessing steps onto J2K client hooks (contributed upstream in 2024) so they can use J2K's more precise symbol resolution.

Seen in

Last updated · 319 distilled / 1,201 read