Hi folks, I created a PR here:
https://github.com/apache/groovy/pull/2097 For issue GROOVY-11432: https://issues.apache.org/jira/browse/GROOVY-11432 It provides a fairly simple mechanism to support method references/method pointers in annotation members. It piggybacks on the existing closure support. Basically for an example using a closure: @TupleConstructor(post={ assert first && last }) class Person { final String first, last } You could now rewrite like this (to allow the validate method to be used also in other contexts): @TupleConstructor(post=Person::validate) class Person { final String first, last void validate() { assert first && last } } It is rewritten to this: @TupleConstructor(post={ this.withClosureMethod(Person::validate) }) class Person { final String first, last void validate() { assert first && last } } There is nothing to stop other AST transforms from re-wrapping the call to withClosureMethod to be a direct call to some java.util.function.Function/Supplier/Consumer. Note: I added the DGM#withClosureMethod to provide a hook that would work for both dynamic and static Groovy. I believe it would work well for the scenario posed for Timefold/Optaplanner as well as various tweaks we could make to our existing AST transforms and for frameworks like Grails. It also works well with the recent GROOVY-11443 enhancement for design-by-contract scenarios where method references could now be mixed with other method references, or ad-hoc closures to specify pre/post-conditions & invariants. Also, by piggybacking in this way, should Java ever support this feature (as they discussed in [1]), the Java mechanism should not be impacted by this mechanism Let me know if you have any thoughts. . Cheers, Paul. [1] https://mail.openjdk.org/pipermail/core-libs-dev/2018-November/056596.html Cheers, Paul.
