Code10x
Annotations and reflectionmedium3-5 years

A team writes their own annotation, forgets `@Retention(RetentionPolicy.RUNTIME)`, and the reflection-based code that's supposed to act on it never fires — no exception, no warning, the annotated behavior just silently never triggers. Where, precisely, did the annotation actually go?

It didn't disappear — it's sitting in the compiled .class file, fully present, just in an attribute the JVM's own reflection API never reads. Without an explicit @Retention, an annotation defaults to CLASS retention (not SOURCE, and not RUNTIME), which means it's written into a real bytecode attribute called RuntimeInvisibleAnnotations — readable by tools that parse class files directly (javap -v, ASM, a bytecode-weaving library) but never consulted by Class.getAnnotation(), isAnnotationPresent(), or anything else built on java.lang.reflect. Only RUNTIME retention writes the annotation into RuntimeVisibleAnnotations, the one attribute the reflection API actually reads. The code compiles cleanly, the annotation shows up correctly in the IDE and in Javadoc, and at run time getAnnotation() just quietly returns null — there's no exception because, from the JVM's own reflection implementation's point of view, there genuinely is nothing to find in the attribute it looks at.

The lesson behind it →
PreviousA payments service needs to deserialize a polymorphic `PaymentMethod` — `CardPayment`, `BankTransferPayment`, `WalletPayment` — from a JSON field that names the subtype. A junior engineer suggests enabling `ObjectMapper.enableDefaultTyping()` so any request body can just work without per-type annotations. Why is that a serious security decision disguised as a convenience one, and what should be done instead?Next A `@Transactional` method on an `OrderService` bean calls another `@Transactional` method on the same class via `this.otherMethod()`. In production, a failure partway through leaves the database in a partially-committed state that the second method's transactionality was supposed to prevent. What actually happened, and why doesn't `@Transactional` protect this call?
More on Annotations and reflection
A `@Transactional` method on an `OrderService` bean calls another `@Transactional` method on the same class via `this.otherMethod()`. In production, a failure partway through leaves the database in a partially-committed state that the second method's transactionality was supposed to prevent. What actually happened, and why doesn't `@Transactional` protect this call?