{"id":595295,"date":"2025-09-04T12:56:15","date_gmt":"2025-09-04T11:56:15","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=595295"},"modified":"2025-10-26T23:05:55","modified_gmt":"2025-10-26T22:05:55","slug":"improved-annotation-handling-in-kotlin-2-2-less-boilerplate-fewer-surprises","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/pt-br\/idea\/2025\/09\/improved-annotation-handling-in-kotlin-2-2-less-boilerplate-fewer-surprises","title":{"rendered":"Improved Annotation Handling in Kotlin 2.2: Less Boilerplate, Fewer Surprises\u00a0"},"content":{"rendered":"\n

Many developers have run into subtle issues with annotations when working with Kotlin and frameworks like Spring or JPA-based persistence frameworks. For instance, an annotation applied to a constructor parameter might not always end up in the property or backing field where the framework expects it.<\/p>\n\n\n\n

This often means annotations don\u2019t land where they\u2019re needed. For example, bean validation checks might only happen when the object was first created, but not when its properties were later updated. The result? Confusing bugs, surprising runtime behavior, and sometimes even the need to dig into bytecode to see what\u2019s really going on. For example, validation might not be enforced when entities are loaded or updated from the database.<\/p>\n\n\n\n

With Kotlin 2.2, we\u2019re addressing this problem. A new default rule makes annotations land where developers expect them to, reducing boilerplate and aligning better with popular frameworks.<\/p>\n\n\n\n

Consider this simple JPA entity:<\/p>\n\n\n\n

@Entity\nclass Order(\n\u00a0\u00a0\u00a0\u00a0@Id\n\u00a0\u00a0\u00a0\u00a0@GeneratedValue\n\u00a0\u00a0\u00a0\u00a0val id: Long,\n\n\u00a0\u00a0\u00a0\u00a0@NotBlank\n\u00a0\u00a0\u00a0\u00a0var name: String,\n\n\u00a0\u00a0\u00a0\u00a0@Email\n\u00a0\u00a0\u00a0\u00a0var email: String\n)<\/pre>\n\n\n\n
At first glance this looks correct. But in Kotlin versions before 2.2, the default rule applied these annotations only to the constructor parameter (@param<\/code>).<\/p>\n\n\n\n
If we look at the decompiled code, it actually becomes:<\/p>\n\n\n\n
public class Order {\n\u00a0\u00a0@Id\n\u00a0\u00a0@GeneratedValue\n\u00a0\u00a0private final long id;\n\n\u00a0\u00a0@NotNull\n\u00a0\u00a0private String name;\n\n\u00a0\u00a0@NotNull\n\u00a0\u00a0private String email;\n\n  public Order(long id, @NotBlank @NotNull String name, @Email @NotNull String email) {\n      Intrinsics.checkNotNullParameter(name, \"name\");\n      Intrinsics.checkNotNullParameter(email, \"email\");\n      super();\n      this.id = id;\n      this.name = name;\n      this.email = email;\n   }\n\u2026\n}<\/pre>\n\n\n\n
Validation annotations like @NotBlank<\/code> and @Email<\/code> weren\u2019t placed on the field\/property \u2013 they only validated object construction, not property updates.<\/p>\n\n\n\n
This mismatch has been a common source of confusion.<\/p>\n\n\n\n
Previous workaround: Explicit use-site targets<\/strong><\/p>\n\n\n\n
The fix was to explicitly mark the targets, for example with @field<\/code>:<\/p>\n\n\n\n
@Entity\nclass Order(\n\u00a0\u00a0\u00a0\u00a0@field:Id\n\u00a0\u00a0\u00a0\u00a0@GeneratedValue\n\u00a0\u00a0\u00a0\u00a0val id: Long,\n\n\u00a0\u00a0\u00a0\u00a0@field:NotNull\n\u00a0\u00a0\u00a0\u00a0var name: String,\n\n\u00a0\u00a0\u00a0\u00a0@field:Email\n\u00a0\u00a0\u00a0\u00a0var email: String\n)<\/pre>\n\n\n\n
so that becomes:<\/p>\n\n\n\n
public class Order {\n\u00a0\u00a0@Id\n\u00a0\u00a0@GeneratedValue\n\u00a0\u00a0private final long id;\n\n\u00a0\u00a0@NotBlank\n\u00a0\u00a0@NotNull\n\u00a0\u00a0private String name;\n\n\u00a0\u00a0@Email\n\u00a0\u00a0@NotNull\n\u00a0\u00a0private String email;\n\u2026\n}<\/pre>\n\n\n\n
This approach works, but clutters the code with extra syntax. It also requires developers to know about Kotlin\u2019s use-site targets and remember which one each framework expects.<\/p>\n\n\n\n
Kotlin 2.2: A new default that just works<\/strong><\/p>\n\n\n\n
Starting with Kotlin 2.2, annotations without an explicit use-site target are applied to the constructor parameter and the property or field, aligning behavior with what most frameworks expect.<\/p>\n\n\n\n
That means our original code now works as expected, without requiring any additional annotations:<\/p>\n\n\n\n
@Entity\nclass Order(\n\u00a0\u00a0\u00a0\u00a0@Id\n\u00a0\u00a0\u00a0\u00a0@GeneratedValue\n\u00a0\u00a0\u00a0\u00a0val id: Long,\n\n\u00a0\u00a0\u00a0\u00a0@NotBlank\n\u00a0\u00a0\u00a0\u00a0var name: String,\n\n\u00a0\u00a0\u00a0\u00a0@Email\n\u00a0\u00a0\u00a0\u00a0var email: String\n)<\/pre>\n\n\n\n
With the new rule:<\/strong><\/p>\n\n\n\n