Java EE取代了Scala？

Question

许多Java x Scala比较似乎只关注语言(语法、集合api、角色等)，但是企业应用程序开发呢？

如果您想使用Scala构建分布式企业系统，您会使用Scala语法编写传统的Java EE应用程序(例如，使用Scala语法的EJB兼容类)并在Java EE容器中运行它，还是在Scala生态系统中有Java EE的替代品？

如果是第二个，那么到目前为止，我找到的最接近的是类型安全堆栈；它是Scala对Java EE容器的替代吗？

Akka是JMS (以及可能的会话Beans)的替代品吗?或者您的Scala系统仍然会利用Java服务吗？

Answer 1

井,

Scala / Akka为系统开发中的许多常见陷阱提供了不同的概念。仅将其中几个与Java EE进行比较：

=> JavaBeans：

可变的数据结构是非常糟糕的，并且不是线程安全的。将它们放入容器中并不会改变任何事情。取而代之的是使用不可变的数据结构，就像scala对CaseClasses强制执行的那样。

=> EJB：

EJB的组合太糟糕了。实际问题是，EJB需要具有高级别的内聚力，才能在可重用性方面发挥作用，而在实践中很难做到这一点。把它们塞进容器里也不会让它变得更好。在Scala中，使用特征进行组合使您能够通过受f-bounded多态性保护的构造函数注入来使用即席组合。生活可以如此简单。

=>事务：

是的，事务管理器已经让事情变得更好了，但它仍然需要大型Java EE堆栈才能使其工作。在Scala中，只需使用akka提供的软件事务内存(STM)就可以了。

=>持久化：

我们真的需要ORM吗？像squeryl.org这样的项目向Scala添加了强类型的LINQ。与Hibernate所做的重量级查询语言映射不同，它只是将查询集成到scala中，并由编译器进行全面检查。当然，这只适用于关系数据库。对于非sql，还有其他可用的解决方案。

=> Scaling？

Java EE集群？我还需要说更多吗？

在akka中，您只需再添加几个服务器，系统就可以正常扩展。为什么？因为远程参与者的处理和访问方式与本地参与者相同，其他一切都只是配置分布式参与者系统的问题。Akka是基于Erlang模型的，所以他们不是寻找5-9的正常运行时间，而是在全系统负载下寻找9-9的正常运行时间。同时，akka是如此简单和轻量级，你可以在Android上使用它。您会尝试在Android上运行Java EE吗？

https://github.com/gseitz/DiningAkkaDroids

需要明确的是，也许在十年前，Java EE是如何构建大型企业级软件问题的答案，一旦Spring使其可用，它可能是当时最好的解决方案。

今天，世界已经发生了很大的变化，大多数旧的答案不再适合今天的现实。Scala并不完美，但如果它真的只有一行，最好是这样：

在scala中，我只用了Java和容器设置所需时间的一小部分就完成了实际编程。

即使是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

Answer 2

Akka确实是JMS的一种“替代品”。在这个想法(和你的问题)的背后，它确实是一种范式的改变，我们必须意识到这一点，但从这个事实开始，我认为akka在未来有机会在未来的几个用途中得到非常广泛的使用，从消息传递到分布式以太原并发平台之间的集成。

Typesafe堆栈是一个堆栈，所以我发现考虑到Java EE contanier是没有用的。

最后，第一个答案:如果您想使用EJB语法，请考虑使用注释，您应该有机会以与java大致相同的方式编写EJB，再加上一些scala的“语法糖”。

Answer 3

如果你想要Java EE，你可以直接在Scala中使用Java EE。然而，在Scala社区中，我不知道有谁不想摆脱Java EE (或继续避免它)。