@BeanProperty and @BooleanBeanProperty should not replicate field annotations onto generated methods

[scabug]

If I annotate a field like so:

@foo
@BeanProperty
var bar: String = _

... the generated methods getBar and setBar are given the @foo annotation also. This causes problems for widely used Java libraries that rely on the convention of either the field OR the method being annotated.

Given @BeanProperty's express purpose for Java interoperability, the default behavior for @BeanProperty should be aligned with the prevailing Java convention. The generated getter and setter should not have the underlying field's annotations added.

If a developer wishes to have annotations defined on the Java-visible getter or setter, they should define those methods explicitly in the Scala class, and add the desired annotations manually.

This is not a duplicate of #1846 or #2245. Those tickets both raise this issue, but request that the problem be addressed by either adding more metadata at the Scala language level, or by providing compiler plugins that add knowledge of the annotations in use. For the @BeanProperty use cases, this is overkill. I am requesting that incorrect compiler behavior be removed.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-2252?orig=1
Reporter: Chris Herron (cherro)

[scabug]

James Strachan (jstrachan) said:
would this only apply to the use of @BeanProperty - or are you saying this should apply to all annotations?

i.e. annotations would always only be on the field and not on the accessor/getter an mutator/setter?

[scabug]

Chris Herron (cherro) said:
Replying to [comment:1 jstrachan]:

would this only apply to the use of @BeanProperty - or are you saying this should apply to all annotations?

I'm only focusing on the behavior of scalac when it encounters @BeanProperty or @BooleanBeanProperty and subsequently generates JavaBean compliant getters/setters. My thinking is that the impact of this change would be low because its targeting Java interop.

I'm not sure about applying this 'fields-only' restriction to the regular Scala-generated mutator functions - simply because I don't know how broadly the current behavior is depended-upon. Absent that knowledge, since you ask, I personally think it would be okay to reduce it all to field-only, and leave it to the developer to explicitly define the mutator methods, if that is where he wishes the annotation to live. I think this expresses the developer's intent more directly, rather than trying to pass extra metadata to the mutator-generation behavior.

That begs the question, what would the impact of eliminating (wholesale) this annotation replication be?

[scabug]

Chris Herron (cherro) said:
Having thought about this more, I think that while it would be safe (and correct) to omit a field's annotations on a getter/setter generated by @BeanProperty and @BooleanBeanProperty, it would not be safe to omit them on the regular Scala generated accessor/mutator (def x():Foo and def x_(foo:Foo)). I suspect that this would impact Scala's adherence to the Uniform Access Principle, and the assumptions that come with it.

So I now understand why James and Florian's tickets (#2245, #1846) take the approaches they do. Unfortunately it seems that the UAP and Scala interoperability with Java annotation conventions are mutually conflicting requirements.

Given that, I still feel that this bug is valid in the limited scope of the @BeanProperty and @BooleanBeanProperty behavior.

[scabug]

Bart Schuller (arrowax) said:
Replying to [comment:3 cherro]:

Having thought about this more, I think that while it would be safe (and correct) to omit a field's annotations on a getter/setter generated by @BeanProperty and @BooleanBeanProperty, it would not be safe to omit them on the regular Scala generated accessor/mutator (def x():Foo and def x_(foo:Foo)). I suspect that this would impact Scala's adherence to the Uniform Access Principle, and the assumptions that come with it.

I don't know about the UAP (I don't think that has any relation with annotations), but I do know about the actual trouble with field annotations getting replicated to accessors. JPA, JSR-299, Spring: there are lots of frameworks and standards using annotations to say inject a value here. What does it mean to have such an annotation on a getter/accessor? Do you know what these existing frameworks do when they encounter one? I'll tell you: they break.

[scabug]

@lrytz said:
fixed in r18787 and r18829