Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

<h3>Background</h3>

<p>Groovy's property mechanism provides a short-hand which simplifies defining typical <em>JavaBean-style</em> classes. You simply define the property with no explicit visibility and it is replaced at the bytecode level by a private backing variable, a public setter and a public getter. To the Java world, all three parts are visible. In the Groovy world, conceptually it is OK to just think about the property - Groovy's property notation comes in to play so that using the setter or getter looks like using the property as if it was a field.</p>

<p>This works well but introduces a slight complication with annotations. When using the non-property approach, there are three places in the source code where an annotation may be added (the field, the setter and the getter). With the property approach (idiomatic Groovy) there is just one place available in the source to place an annotation.</p>

<h3>Current Behaviour</h3>

<p>Currently if an annotation is applied to a property, the compiler will attempt to apply the annotation to the field, the setter and the getter. If any of these fails (e.g. some annotations may apply only to methods or only to fields) the code won't compile.</p>

<h3>PROPOSAL: Smarter annotation assignment</h3>

<p>Use the java.lang.annotation.Target of any annotations to determine where the annotation will be included in the final class.</p>

<p>If the @Target of the used annotation marks the annotation as usable only on FIELD level, then the annotation will be attached to the generated field.</p>

<p>If the @Target of the used annotation marks the annotation as usable on METHOD level, then the annotation will be attached to the generated getter and setter.</p>

<p>If the @Target of the used annotation marks the annotation as usable on both FIELD and METHOD level, then the annotation will be attached to all the generated class elements.</p>

<p>Obviously, if multiple annotations are used, there is the possibility of the annotations being split across the generated class elements, e.g. I can use both a field and a method annotation. The field annotation will be attached to the field (and ignored for the getters and setters) while the method annotation will be attached just to the methods.</p>

<h3>PROPOSAL: Additional annotation classification mechanism</h3>

<p>Sometimes it is desirable to be more selective with annotation than is possible even with smarter annotation assignment, e.g. placing an annotation on just one of the setter or getter. Sometimes an annotation might be possible on both fields and methods but in a particular example we want to apply it to just one. To achieve this we need additional syntax to express how we want to classify an annotation.</p>

<p>One way to do this is to use a synthetic annotation as a prefix to the real annotation. A @Target annotation appears in Groovy code at the source level, but it is only synthetic. It has no real definition. It will be like a compiler flag only, and completely ignored in the output.</p>

<p>The @Target annotation allows the user to further refine where the compiler should attach an annotation. After it has been used by the compiler, it is completely discarded. The Groovy @Target annotation will further specify if an annotation will be attached to a FIELD, GETTER or SETTER, but will never contradict the Java @Target annotation. In case such a contradiction occurs the Groovy compiler must emit an error.</p>

<p>Last, but not least I should mention that there will be no naming conflict between the Java java.lang.annotation.Target annotation and the Groovy Target annotation (probably groovy.lang.annotation.Target), because they will be living in completely different context.</p>

<p>An example:</p>

<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
@Target([FIELD]) @AutoPopulate(defaultValue="bar")
@Target([GETTER]) @ManagedAttribute(currencyTimeLimit=15)
@Target([SETTER]) @ManagedAttribute(persistPolicy="OnUpdate")
int base = 10
</pre></td></tr></table>

<p>As an alternative, we could come up with some other syntax to achieve the same result, e.g. here might be some other ways to write the above:</p>

<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
@[FIELD]AutoPopulate(defaultValue="bar")
@[GETTER]ManagedAttribute(currencyTimeLimit=15)
@[SETTER]ManagedAttribute(persistPolicy="OnUpdate")
int base = 10
</pre></td></tr></table>

<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
@AutoPopulate[FIELD](defaultValue="bar")
@ManagedAttribute[GETTER](currencyTimeLimit=15)
@ManagedAttribute[SETTER](persistPolicy="OnUpdate")
int base = 10
</pre></td></tr></table>

<p>Or this (using a synthetic annotation parameter):</p>

<table class="wysiwyg-macro" data-macro-name="code" style="background-image: url(/plugins/servlet/confluence/placeholder/macro-heading?definition=e2NvZGV9&amp;locale=en_GB&amp;version=2); background-repeat: no-repeat;" data-macro-body-type="PLAIN_TEXT"><tr><td class="wysiwyg-macro-body"><pre>
@AutoPopulate(groovyTarget='field', defaultValue="bar")
@ManagedAttribute(groovyTarget='getter', currencyTimeLimit=15)
@ManagedAttribute(groovyTarget='setter', persistPolicy="OnUpdate")
int base = 10
</pre></td></tr></table>