having a standard Spring/Guice/JSR250/JSR330/JSR299 aware IoC annotation compiler plugin would really help

[scabug]

Using Java based IoC frameworks in Scala is uglier than using pure Java.

Examples here...
http://www.nabble.com/-scala--Annotating-a-field-without-annotating-the-associated-methods---Spring--@Autowired-annotation-td23596908.html

or section 3
http://www.brainoutprintln.com/?p=166

In Java code we can write code like this...

// Java
class MyComponent {
    @Autowired 
    private Service service;
}

however we cannot do this in Scala...

// Scala
class MyComponent {
    @Autowired
    var service = _
}

as by default Scala adds the annotation to the field, getter and setter methods which make all the IoC frameworks barf.

A scala compiler plugin which by default knew about all the standard & common IoC annotations would be cool.

e.g. out of the box any of these annotations would by default be placed only on the setter method...

• javax.annotation.Resource
• org.springframework.beans.factory.annotation.Autowired
• com.google.inject.Inject
• javax.inject.Inject

common IoC frameworks for further reference...

• http://code.google.com/p/google-guice/
• http://code.google.com/p/atinject/
• http://springsource.org/

Am thinking a compiler plugin which allowed you to define rules of which elements get the annotation (field, getter, setter) - which came out of the box with rules for all the common Java frameworks & standards - but maybe let folks extend it to add other frameworks?

Then folks using spring/guice/JSR250/JSR299/JSR330 could just depend on the IoC compiler plugin and all of a sudden annotation based IoC becomes much more scala-ish

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-2245?orig=1
Reporter: James Strachan (jstrachan)

[scabug]

Kris Nuttycombe (nuttycom) said:
#1846 is closely related to this, and a solution to that one would probably satisfy here as well.

[scabug]

James Strachan (jstrachan) said:
@nuttycom I'd prefer Scala code to look like this...

  class MyComponent {
    @Autowired var service = _
  }

i.e. that scala code can use the various IoC annotations (as well as JPA annotations and countless others from the Java world) natively without having to create nested annotation wrappers for everything and use the nested annotations instead.

i.e. the compiler plugin decides how certain annotations get copied to field/getter/setter methods at bytecode generation - rather than the user having to use explicit nested annotations at the call site.

[scabug]

James Strachan (jstrachan) said:
@nuttycom or maybe the compiler plugin would output the nested annotations - is that what you meant? so the programmer uses the well known IoC / JPA annotations directly - then the compiler plugin outputs the nested annotations instead - then the bytecode is generated with the annotation on the correct call site?

[scabug]

James Strachan (jstrachan) said:
Just to clarify, my motivation with this issue is to let folks use the common Java IoC frameworks like Spring/Guice/JSR250/JSR330/JSR299 in a natural way with Scala's fields/getters/setters with minimal noise & boiler plate code. So I'd like developers to be able to write Scala code like this...

 class MyComponent {
    @Autowired var service = _
  }

where @Autowired could be replaced by a number of other IoC annotations from the various frameworks such as @resource or @Inject from Guice/JSR330 - there's about say 10 common well used annotations).

How's this for a really simple mechanism which would solve this problem very easily - as well as provide a simple mechanism folks can adapt and extend...

When adding annotations to fields/getters/setters in Scala, the compiler loads the 'annotation defaults' configuration. To do this it loads the default properties file from somewhere (these are the out of the box defaults which tries to do the right thing for most common IoC frameworks) - say at META-INF/services/scala/compiler-annotations.default.properties

Then it loads all of the custom files (letting users overload the out of the box defaults) it can find at the URI META-INF/services/scala/compiler-annotations.properties

It loads the defaults into a Properties object then overwrites entries with any custom extensions it can find on the classpath. (It could maybe warn if 2 extension properties files have conflicting entries).

The properties file should look like this...

javax.annotation.Resource = setter
org.springframework.beans.factory.annotation.Autowired = setter
com.google.inject.Inject = setter
javax.inject.Inject = setter

The above supports JSR330, JSR250 and Guice - with a little bit of Spring. A few more entries and all of Spring/Guice/JSR250/JSR330/JSR299 would be supported too.

If you've not guessed by now, the format of the properties file is

annotationClassName = [field] [getter] [setter]

(order isn't important) so that you can list which elements get the actual bytecode annotation.

The default value if no entry is found for a given annotation type is "field getter setter".

The aforementioned example would then default the annotations in bytecode to be restricted just to the setters.

Having said that this should be an optional compiler plugin earlier in this issue - I'm now thinking, given the importance of IoC frameworks on the Java platform - that Scala's compiler should ship with this functionality (and a good set of defaults which I'm more than happy to provide) out of the box by default.

i.e. out of the box, Scala's compiler should work great for folks using Spring/Guice/JSR250/JSR330/JSR299 annotations

I'll happily provide a complete default properties file if you like?

[scabug]

Chris Herron (cherro) said:
It doesn't make sense to address this case-by-case in a compiler plugin. I have suggested a simpler solution in #2252.

[scabug]

James Strachan (jstrachan) said:
does #2252 only apply if @BeanProperty was used too right?

FWIW I don't want to have to use @BeanProperty just to be able to use @Inject, @Autowired or the other IoC & JPA annotations. Forcing the addition of new annotations just to get around scala compiler issues, we might as well just go the whole hog and use explicit nested annotations to fix this.

i.e. I still think this issue is relevant; we need a DRY way to default which elements get the annotation at the bytecode level - the field and the accessor/getter and mutator/setter method - irrespective of the use of @BeanProperty

Also for IoC injections, you might want the annotation on the setter/mutator so that things work nicely with inheritance rather than always being on the field.

I guess you could say for #2252 you are just picking a single default setting (on the field only right?) whereas the solution in this ticket provides a way to provide per-annotation-type defaults so framework developers can choose the best default for a particular annotation. I'm not sure if field-only makes sense for all annotations in IoC/JPA etc

[scabug]

Chris Herron (cherro) said:
Echoing my comment in #2252 in response to jstrachan:
I think it would be simpler to eliminate the annotation replication from fields onto generated functions entirely. If the developer requires an annotation on the function instead of the field, he would omit the annotation from said field, and explicitly declare one or both accessor/mutator functions with the desired annotations upon them. For example, we go from:

  @Foo
  var bar: String = _

to defining a (Scala convention) mutator on a virtual property:

  var barInternal: String = _

  @Foo
  def bar_(b: String) = {
    barInternal = bar
  }

[scabug]

James Strachan (jstrachan) said:
@cherro I totally agree that the default should be for annotations to only be added to fields by default. This would solve lots of problems with IoC/JPA etc.

Folks can always use the proposed nested annotations or as you say, write a custom mutator.

Having said that; I think there's a need to map in a DRY way, which of the generated elements (fields, accessors, mutators) the annotation goes on a per annotation basis more easily.

e.g. JAXB comes to mind; there are times you want them to be on fields or on properties.

[scabug]

@rossjudson said:
The current action of @!BeanProperty is to copy the annotations to the generated functions. This is incorrect behavior, as annotations are supposed to have their applicability be limited by !ElementType. Copying an annotation that is restricted to field types to a generated method isn't desirable. We need rules to decide when annotations should be copied and when they should be moved. It shouldn't rely on anything other than standard language constructs, as well.

I suggest something like the following:

First, check the element type restrictions and move or copy as appropriate, if it can be determined from those. Second, obey instructions supplied in other annotations:

@AnnotateGenerated(@Getters)
class Person {
   @XmlAttribute
   var name = ""
   @XmlAttribute
   var age = 10
   @XmlValue
   var details = ""
}

The parameter to @!AnnotateGenerated might be @getterS, @setters, @fields, @accessors (getters and setters), or @ALL. The current behavior corresponds to @ALL.

Allow !AnnotateGenerated on packages, classes, and members, so the annotations can applied to specific scopes.

It might make sense to further refine the instruction by annotation type:

@AnnotateGenerated(XmlAttribute.class, @Getters)

[scabug]

@lrytz said:
Please join the discussion on the scala mailing list: http://www.nabble.com/-scala--field-annotations%2C-getters-setters-and-BeanProperty-td24970781.html.
I'd love to see more feedback on the issue there.

Also note a related post: http://www.nabble.com/-scala--properties---bean-properties-td25028167.html.

We use our mailing lists (http://www.scala-lang.org/node/199) for public discussions on design issues.

[scabug]

@lrytz said:
fixed in r18787 and r18829