Thanks. I'm familiar with Escalante. Besides the issue that unless I'm mistaken it's not yet production-ready, we don't want to switch app servers - we want to use JBoss, with mostly Java code, but a few Scala modules.
Perhaps that is a bad idea. Perhaps there is a reason you don't read much about this on the blogs & forums. That is what I'm trying to find out.
Ok, another couple days and I'll have to definitely conclude that nobody is doing this - wish I understood why tho. Perhaps writing & deploying the code will give me the answer.
Now leaning to using Scala in a separate VM for cleaner separation - the Akka kernel actually. It just makes more sense architcturally anyway.
Surely running Scala classes in the AS7 VM is going to be fine in general, but I wonder if there are any gotchas.
For closure/for the community, I wanted to report back that using Scala in JBoss AS 7 works just beautifully. Some details:
- Follow standard Maven Scala guidelines for the build - you can mix Scala & Java in the same project with src/main/java and src/main/scala dirs.
- Using Idea 12, I can also debug Scala code running under JBoss
It works like a charm (it should, right, since this is just JVM bytecode). If this isn't widespread, I can't say I understand why, since Scala is so much superior to Java as a language (ducking). JBoss & Scala are two great technologies that work great together. (I apologize if this smacks of a Reeses commercial.)
Agree. If you follow the standard Maven structure and put your Scala code under src/main/scala, the maven plugin (http://davidb.github.io/scala-maven-plugin/) takes care for the rest.
In particular it allows you to have Scala classes referring to your Java classes and the opposite at the same time (while this is the expected behavior, it isn't obvious to implement since the the Java compiler doesn't know Scala).
Also, we are using Akka in Scala from our EJBs which is a little tricky because Akka should be used in a non-blocking manner which means EJB calls return before Akka is done. To workaround this, our Akka actors are calling back to the EJB system when done.
I've written a number of small tools in Scala which are deployed to JBoss, and for the most part it works without any special effort. There are a few places where Java and Scala aren't identical which causes some minor pain.
First up is annotations. If you write "@SomeAnnotation @BeanProperty var foo", did you want @SomeAnnotation on the private field, the scala getter method foo() or the bean getter method getFoo()? You can use the scala.annotation.target._ meta-annotations to control that, but if you are writing annotation-heavy code (e.g. JPA entities) it can get tedious and verbose.
Second is due to idiomatic style differences. In scala immutable classes are preferred, but most people write EE with lots of injection (CDI, @EJB, etc) into private fields. It's not overly well known, but in Scala you can write "class Foo @Inject() (x: Int, y: String)" to annotate the constructor. You must have a parameter list for it, even if empty. You need to use the above meta-annoation if you want it on the field that a constructor param creates.
Personally, I think that before writing an app you need to make an up-front decision about whether you want to write:
a) an EE app, in Scala
b) an "idiomatic" OO/FP hybrid style Scala app utilising EE, or
c) a mostly FP Scala app, using some EE pieces at the edge
The way you approach writing the app will vary a lot between those three, and switching between that can involve re-writing a large amount of code.