Proposal to change default annotation processing policy in JDK 23

Original Article ↗ Hacker News Discussion ↗

Security motivation and risk model

  • Goal: stop annotation processors on the classpath from running implicitly during javac, reducing risk from supply‑chain and file‑dropping attacks.
  • Supporters say compilers in 2024 shouldn’t execute arbitrary user code by default; “secure by default, opt‑in for power” is appropriate.
  • Critics argue exploitation is non‑trivial and often equivalent to already having arbitrary code on the runtime classpath. Others counter that compile‑time and runtime classpaths differ (e.g., test‑only, compile‑only, transitive deps) and build machines/CI can be more privileged than runtimes.
  • Some stress this is as much about integrity (what invariants the platform can trust) as about security.

Impact on builds and developer experience

  • Many expect builds to break when moving to JDK 23 because common annotation processors won’t run automatically.
  • There’s wide agreement many teams will just enable “all‑on” (-proc:full), partially negating security benefits.
  • Proposed mitigations:
    • Tools to list processors on the classpath and their purposes.
    • Allow/deny lists, with an auto‑populate mode based on an initial scan.
  • Others argue that even if many opt out, those who care gain needed control, and the default should still be restrictive.

Lombok and annotation processors

  • Clarified that Lombok’s core behavior isn’t a standard annotation processor; it bootstraps via one but actually hooks into javac internals.
  • Debate over whether the change is part of a “war on Lombok” versus a neutral enforcement of clear boundaries and explicit configuration for tools that modify compiler behavior or violate the Java spec.

Java philosophy, backwards compatibility, and Security Manager

  • Some see this and past module/reflection changes as a backward‑compatibility “crusade.”
  • Others respond that:
    • Only internal/unsupported APIs are being restricted.
    • Libraries should not unilaterally bypass encapsulation; applications must explicitly grant such powers.
  • Security Manager’s deprecation/removal is defended as removing a rarely used but costly feature that blocked modern features; critics lament losing an in‑process sandbox for plugins with no direct replacement.

Ecosystem effects and alternatives

  • Mentioned affected processors include Immutables, AutoValue, MapStruct, Hibernate tooling, Checker Framework, etc.
  • Some welcome the change as pushing Java away from “magic” (especially annotation‑driven) and toward more explicit language features, citing Kotlin as a preferable model for reducing boilerplate.