Java EE replacement for Scala?

Bernardo Bennett picture Bernardo Bennett · Feb 7, 2013 · Viewed 8k times · Source

Many Java x Scala comparisons seem to focus on the language alone (syntax, collections api, actors, etc) but what about enterprise application development?

If you want to build a distributed enterprise system using Scala, would you code a traditional Java EE application using Scala syntax (e.g. EJB compatible class using Scala syntax) and run it in a Java EE container, or is there a Java EE replacement in the Scala ecosystem?

If the second, so far the closest thing I found is the typesafe stack; is it Scala's replacement for a Java EE container?

Is Akka a JMS (and possibly Session Beans) replacement or would your Scala system still leverage Java EE services?

Answer

Marvin.Hansen picture Marvin.Hansen · Feb 8, 2013

Well,
Scala / Akka offer different concepts for many of the common pitfalls in system development. To compare just a few to Java EE:

=> JavaBeans:
Mutable Data-structures are just plain evil and not thread-safe. Putting them into a container doesn't change anything. Use immutable data structures instead, as scala enforces with CaseClasses.

=> EJB:
Composition of EJBs just sucks. The actual problem is that EJBs need to have a high level of cohesion to be useful in terms of re-usability which is hardly the case in practice. Stuffing them into a container wan't make it any better. In Scala, using traits, for composition enables you to use ad-hoc composition through constructor injection protected by f-bounded polymorphism. Life can be so easy.

=> Transactions:
Yes transaction managers already make things better but it's still requires the big Java EE stack to make it work. In Scala, just use Software Transactional Memory (STM) as provided by akka and you're done.

=> Persistence:
Do we really need ORM? Projects like squeryl.org add strongly typed LINQ to Scala. Instead of heavy-weight query language mapping, as Hibernate does, it just integrates queries into scala, fully checked by the compiler. This is of course only true for relational DB's. For no-sql, there are other solutions available.

=> Scaling?
Clustering Java EE? Do I need to say more?
In akka you just add a few more server and the system just scales. Why? Because remote actors are treated and accessed the same way as local actors and everything else is just a matter of configuring your distributed actor system. Akka is based on the Erlang model, so they do not look for five-nine up-time but nine-nine up-time under full system load. At the same time, akka is so easy and light-weight that you can use it on Android. Would you try to run Java EE on Android?
https://github.com/gseitz/DiningAkkaDroids

To be clear, maybe ten years ago, Java EE was the answer to the question how to build large enterprise grade software and, once Spring has made it usable, it was maybe the best available solution at those days.
Today, the world has changed a lot and most of the old answers do not fit today's reality anymore. Scala, is not perfect but if it really comes down to one single line it would b be this:

In scala, I get my actual programming done in a fraction of time the Java EE and container setup would take.

Even Spring, as the framework of choice for Java EE is moving towards scala:

http://blog.springsource.org/2012/12/10/introducing-spring-scala/

To start with both, concepts and best practices for Akka, there is a handy book called "Akka Essential"

http://www.akkaessentials.in/2012/12/adding-turbchargers-to-jee-apps.html