Why doesn’t Java allow method references in annotations?

The JVM’s annotation format is deliberately limited to values that can be stored as constants or symbolic references. A method reference normally represents executable behavior and may require generating a lambda or implementation class, so it doesn’t map directly to an annotation element. It could potentially be implemented by generating extra classes at compile time, but that would add language, compiler, reflection, and compatibility complexity for a relatively specialized feature.

There’s also an important distinction between a method reference and a method literal. `obj::method` is an expression that produces a functional-interface instance, while an annotation needs a value that can be recorded without executing code. If the goal is simply to identify a method for static analysis, a string or custom annotation containing a method name is the usual workaround, although it loses compile-time safety.

This would require more than just adding another annotation value type. Java method references don’t have a standalone method-reference type; they are converted to a particular functional interface. A reference such as `this::lock` therefore needs a target type, and overloaded methods can make the intended declaration ambiguous. Java would need some form of method or field literal, plus rules for resolving and storing it. For now, annotations generally use a class literal or a string containing a member name, with an annotation processor or framework validating it.