许多 Java x Scala 比较似乎只关注语言（语法、集合 api、actor 等），但企业应用程序开发呢？
如果您想使用 Scala 构建分布式企业系统，您会使用 Scala 语法（例如，使用 Scala 语法的 EJB 兼容类）编写传统的 Java EE 应用程序并在 Java EE 容器中运行它，或者是否有 Java EE 替代品？ Scala 生态系统？
如果是第二个，到目前为止我发现的最接近的是类型安全堆栈；它是 Scala 替代 Java EE 容器的吗？
Akka 是 JMS（可能还有 Session Beans）的替代品，还是您的 Scala 系统仍会利用 Java EE 服务？
好吧，
Scala / Akka 为系统开发中的许多常见陷阱提供了不同的概念。仅将一些与 Java EE 进行比较：
=> JavaBeans：
可变数据结构只是邪恶的，不是线程安全的。将它们放入容器中不会改变任何东西。改为使用不可变数据结构，因为 scala 使用 CaseClasses 强制执行。
=> EJB：EJB
的组合很糟糕。实际问题是 EJB 需要具有高度的内聚性才能在可重用性方面发挥作用，而这在实践中几乎没有。把它们塞进一个容器不会让它变得更好。在 Scala 中，使用特征组合，您可以通过受 f 有界多态性保护的构造函数注入来使用临时组合。生活可以如此简单。
=> 事务：
是的，事务管理器已经使事情变得更好，但它仍然需要大型 Java EE 堆栈才能使其工作。在 Scala 中，只需使用 akka 提供的软件事务内存 (STM) 即可。
=> 持久性：
我们真的需要 ORM 吗？像 squeryl.org 这样的项目将强类型 LINQ 添加到 Scala。它不像 Hibernate 那样使用重量级查询语言映射，它只是将查询集成到 scala 中，并由编译器进行全面检查。这当然只适用于关系数据库。对于 no-sql，还有其他可用的解决方案。
=> 缩放？
集群 Java EE？我需要多说吗？
在 akka 中，您只需添加更多服务器，系统就会扩展。为什么？因为远程 Actor 的处理和访问方式与本地 Actor 相同，其他一切都只是配置您的分布式 Actor 系统的问题。Akka 是基于 Erlang 模型的，所以他们不寻找 5-9 的正常运行时间，而是在全系统负载下寻找 9-9 的正常运行时间。同时，akka 非常简单和轻量，您可以在 Android 上使用它。你会尝试在 Android 上运行 Java EE 吗？
https://github.com/gseitz/DiningAkkaDroids
需要明确的是，也许十年前，Java EE 是如何构建大型企业级软件的问题的答案，一旦 Spring 使其可用，它可能是当时最好的可用解决方案。
今天，世界发生了很大变化，大多数旧答案不再适合今天的现实。Scala 并不完美，但如果它真的归结为一行，那就是：
在 scala 中，我在 Java EE 和容器设置所需的一小部分时间内完成了我的实际编程。
甚至 Spring，作为 Java EE 的首选框架，也在向 scala 发展：
http://blog.springsource.org/2012/12/10/introducing-spring-scala/
从 Akka 的概念和最佳实践开始，有一本名为“Akka Essential”的方便的书
http://www.akkaessentials.in/2012/12/adding-turbchargers-to-jee-apps.html
Akka 确实是 JMS 的一种“替代品”。在这个想法（和你的问题）背后，确实是范式的改变，我们必须意识到这一点，但从这个事实开始，我认为 akka 有机会在未来被广泛用于多种用途，从消息传递分布式以太并发平台之间的集成。
类型安全堆栈是一个堆栈，所以我发现认为关于 Java EE 容器是没有用的。
最后，第一个答案：如果你想使用 EJB 语法，请考虑使用注解，你应该有机会或多或少地用与 java 相同的方式编写 EJB，加上一些 scala 的“语法糖”
如果您想要 Java EE，您可以直接使用 Java EE 和 Scala。但是，我不知道 Scala 社区中的任何人都不想摆脱Java EE（或继续避免使用它）。