First-class Scala support in Spring [SPR-7876]

[spring-projects-issues]

Eberhard Wolff opened SPR-7876 and commented

Scala is becoming more popular. It handles some issues Spring solver on the language level (i.e. resource management or its AOP-like features). It would therefore be worth investigating what "Spring for Scala" could look like - Maybe a reimplementation, maybe specific usage patterns, maybe just a sample application?

---

37 votes, 36 watchers

[spring-projects-issues]

Ittay Dror commented

Things I would like to see:

• Support for creating scala collections (so scala:list to create a scala list) and to support conversions.
• Support creating beans from functions. Currently, if I have a bean and I want to inject a function into it, I need to create a class implementing the function trait so I can create a bean from it. It would be nice to be able to define the function inline.
• Support for Scala type of properties. In Scala, foo's getter is the method foo and setter is the method foo_=.

[spring-projects-issues]

Geir Hedemark commented

We are already using spring and scala. My opinion is probably affected by the subset of spring we use. We are heavily invested in java technologies because many scala libraries are poorly documented and have too many bugs, and using java libraries enabled us to swap to java if scala didn't work out for us.

We are using @Component, @Service and @Configurable to get DI in basic scala objects and classes. In effect, we have created an in-application service repository using these constructs. This works fine, and we have only got a handful of lines of XML configuration.

We are using @Autowire and @Resource to inject dependencies. This also works fine, but it would be good to be able to declare the injected beans as "val"s instead of vars, which they are today. I was very glad that we didn't need any @BeanProperty annotation to achieve this. Good work.

I want spring to understand native scala properties. @BeanProperty is a pain. I don't want it in my code if I can help it, mostly because it seems I have to expose the variable behind the getter in order to get public setters and getters.

We are using Spring MVC. All our controllers are written in scala. This works fine for us, but JSP is a pain because it relies heavily on setters and getters, and we will have to find something else.

We have an (un)healthy sprinkling of java.util.* in our code. It would be oh so great if spring knew about scala collections and could deliver and consume them when appropriate.

We are not using the Option class much. Almost none of our frameworks knows how to use them correctly. I would like spring to be able to recognize a property that has been declared to be an Option, and if there is nothing to inject into it, I want that to be a warning, not an error. I have explicitly stated that I can do without it in the code, after all.

Spring made the world better five years ago by wrapping poorly-designed libraries and making them easier to use. Whatever anyone says it is a pain to use old-school java libraries from scala. I want spring to have wrapper libraries that makes my life easier, just as in the old days. Hibernate is a big candidate, as is anything else that wants to return Object.

I want spring to understand AnyRef where that is applicable.

Many scala libraries (scala and akka actors) come without rudimentary test support. Testing of concurrency-related stuff is a real pain. We have written some stuff we need, but this is a problem that is hard to solve right.

(We have a code base that is being actively developed, and we are located in Norway. Our stuff is rough and ready, but if any of you guys want to have a look at the kludges we have to put in place for Spring to work for us I can arrange that. If you want to use parts of our code that might also happen, although I can't decide that for myself)

[spring-projects-issues]

Rostislav Hristov commented

Here is a simple Spring MVC application I ported some time ago. Hopefully it can be helpful until something officially comes out.

https://github.com/asual/summer/tree/master/sample-scala

Overall it still feels like Java a lot but probably that's because I'm pretty new to Scala. The most challenging part was JPA Entity Manager injection which requires AspectJ processing of the generated Java classes.

[spring-projects-issues]

Germán Ferrari commented

I would add to the list of Ittay Dror the ability to use functions wherever Spring expects a callback (e.g. JdbcTemplate)

[spring-projects-issues]

Graham Lea commented

"the ability to use functions wherever Spring expects a callback" --> good idea; may just require implicit functions that can convert from FunctionN[A, B, C] => template class

[spring-projects-issues]

Eberhard Wolff commented

I have created some code to show how Spring and Scala can be integrated at https://github.com/ewolff/scala-spring . Enjoy!

[spring-projects-issues]

Eric Pederson commented

If a Scala "object" (singleton) is annotated with @Component then Spring should use that object as the bean and not instantiate a separate object.

[spring-projects-issues]

Eric Pederson commented

For example:

@Component
object Foo {
def bar = ...
}

[spring-projects-issues]

Ittay Dror commented

I don't think supporting object annotation is good. You should wire all instances through the DI container, not have singletons that the code accesses directly.

[spring-projects-issues]

Eric Pederson commented

Right - I want the container to be able to wire my "objects", and expose my Scala objects as beans.

For example:

@Component
object Foo {
@Autowired
var bar: Bar = _
}

@Component
class Baz {
@Autowired var foo: Foo = _
}

In terms of lifecycle not all beans are instantiated by the container. For example, FactoryBeans allow external objects to become beans.

Or - consider the object Foo above.

@Configuration
class MyConfig {
@Bean
def foo = Foo
}

the above @Bean is equivalent to @Component object Foo {}

[spring-projects-issues]

Eric Pederson commented

Correction, the @Bean publishes Foo as a bean, the same as @Component object Foo {}. But they aren't equivalent as the latter allows the container to inject stuff into Foo.

[spring-projects-issues]

Geir Hedemark commented

We are still using both scala and spring. Please feel free to contact us if you feel the need during the design work.

[spring-projects-issues]

Stefan Gheorghiu commented

Just adding support for Scala-like properties would be a huge step forward. Unfortunately, Spring's BeanWrapperImpl is so monolithic and used explicitly in large number of places, that there is no chance to extend its behavior but fully redesign the whole set of Spring modules.

[spring-projects-issues]

Suminda Dharmasena commented

how about Scala and Groovy DSL which can be used without using XML to start with!

[spring-projects-issues]

Tomasz Nurkiewicz commented

Somewhat related: #7836, see my comment from 14/Oct/11.

[spring-projects-issues]

Eric Pederson commented

Another thing that would be nice - currently if you are using constructor injection it looks like

@Component
class Foo @Autowired()(bar: Bar, baz: Baz) extends Blah

which is ugly.

@Component @Autowired
class Foo(bar: Bar, baz: Baz) extends Blah

or even

@Component
class Foo(bar: Bar, baz: Baz) extends Blah

would be nicer - assuming in the latter case that a @Component is going to have its first constructor autowired.

[spring-projects-issues]

Ittay Dror commented

Also, allow function autowiring. This is useful because many times in spring I use SAM interfaces and functions would reduce the boilerplate associated with creating them and allow better reuse

Something like:
object Module {
@Component
val factory: Foo => Bar = blah blah
}

@Component
class MyClass {
@Autowire
val factory: Foo => Bar = null
}

(Module.factory is fully typed at runtime so this should be possible)

[spring-projects-issues]

Geir Hedemark commented

Ittay: What you are suggesting is working nicely already, if I understand you correctly. We have lots of code looking like this which works just fine:

@Service
class Boink {
@Autowired
private var oddballService:OddballService = _
}

There are two things that bug me about this. One is that the service is a class, not an object, but it is hard to create an instance of it otherwise (we also have objects that only need autowiring, but that is another side of the same coin). The other is that the wired dependency is a var, not a val.

Transactional demarcation and security works just fine.

I would love to see autowiring, transactions, security and a small number of modules stripped from spring and integrated with play and neo4j. Play is a dealchanger, if they can get the documentation straight.

[spring-projects-issues]

Ittay Dror commented

My point was being able to define a field ('factory') as a @Component and allow @Autowire on a val (if the val is private, so a final field, then reflection can be used to change it: http://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection)

[spring-projects-issues]

Geir Hedemark commented

I see. The reason I didn't follow is that I don't understand why you would want to expose a field as a component? I think I am asking why you went to the trouble of declaring the field at all. Can't you just go @Component on the class and @Autowired it in where you have the val?

[spring-projects-issues]

Ittay Dror commented

Functions are instances of a predefined class. I can't annotate the FunctionX class.

[spring-projects-issues]

Geir Hedemark commented

Aaah. I see now. Sorry for being dense.

[spring-projects-issues]

Eric Pederson commented

Hi Ittay, for the factory, I think the @Bean annotation may be the one to use (http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-java-bean-annotation)

[spring-projects-issues]

Felix Müller commented

Hi,

FYI: https://github.com/dickwall/subcut

This is an approach for DI in Scala (although I don't like the idea to mix-in special traits in my classes). But maybe you can gain some impressions from their codebase.

Furthermore I want to add, that injection in Scala object is really important. If you use implicit conversions, they are normally bound by the scope of an object. Consider the case that you want to inject DAOs or services into the objects that are created by one implicit conversion...

So, imho really important: DI for Scala objects. (and inject normal Scala properties without the need for @BeanProperty + injection into vals because vars are normally rarely used in Scala)

• Felix

[spring-projects-issues]

Arjen Poutsma commented

Closing this issue, as we now have a separate portfolio project for our Spring Scala efforts. See http://blog.springsource.org/2012/12/10/introducing-spring-scala/ for an introduction. Source is available at https://github.com/SpringSource/spring-scala, documentation at https://github.com/SpringSource/spring-scala/wiki. Please leave further feature requests at https://jira.springsource.org/browse/SCALA.

[spring-projects-issues]

Stefan Gheorghiu commented

Please have a look at this proposal: https://jira.springsource.org/browse/SPR-10887