Java SE和Scala标准库-最好使用其中之一的情况 [英] Java SE and Scala Standard Library - cases when one of them is preferable

问题描述

我们都知道可以使用Scala中的Java库，反之亦然.但是即使纵观Java SE和Scala标准库的表面，我们也可以注意到它们中有很多部分可以解决相同或至少相似的问题.最简单的示例是集合，并发和IO.我不是这两个专家中的专家，但我怀疑Java SE通常会更广泛，而Scala SL包含概念上更高级的功能(例如actor).问题是，如果我们可以访问这两种库并且有机会使用两种语言，那么当我们应该选择Java SE功能而不是Scala SL时是否有一些建议?

We all know that one can use Java libraries from Scala and vice versa. But even looking over the surface of Java SE and Scala standard library, we can notice that there are many parts in them that solve identical or at least similar problems. The trivial examples are collections, concurrency and IO. I am not an expert in either of two, but I suspect that in general Java SE is broader in size while Scala SL contains more conceptually advanced features (such as actors). The question is, if we have access to both libraries and have an opportunity to use both languages, are there some recommendations when we should choose Java SE features over Scala SL?

推荐答案

Scala库分为两大类:

Scala Libraries fit into two general categories:

1. Scala原始库.这些全部(或几乎全部)用Scala编写.通常，人们会出于充分的理由从头开始编写库.也许Java缺少类似的库，或者也许谁写了Scala的人都认为Java等效项有严重的局限性.

收藏就是这样一个例子.

Collections is one such example.

Java库上的
1. Scala包装器.在这些情况下，Scala使用适配器模式(或其他类似模式之一)来提供对Scala友好的API.这些API更加流利，可以与重要的Scala类(例如collections和Option)很好地集成在一起，并且经常利用强大的Scala功能(例如traits)来减少样板.

1. Scala Wrappers over Java Libraries. In these cases, Scala uses an adapter pattern (or one of the other similar patterns) to provide a Scala-friendly API. These APIs are more fluent, integrate well with important Scala classes (such as collections and Option), and often make use of powerful Scala features such as traits to decrease boilerplate.

这些库很少提供比Java提供的功能更多的功能，但是极大地减少了样板，并使使用它们的代码更加惯用.但是，它们通常仅表示Java提供的全部功能的一部分.根据库的不同，通过访问底层Java类来扩展它可能或不可能或不容易.

These libraries rarely offer more functionality than what Java provides, but reduces boilerplate enormously and makes code using them more idiomatic. Often, however, they present just a subset of the total functionality provided by Java. Depending on the library, it may or may not be possible or easy to extend it by accessing the underlying Java classes.

Scala Swing是很好的例子.

Scala Swing is great example of these.

在scala.io的特殊情况下，它不是一个简单的包装库，而是仅用于处理惯用的Scala API的简单常见脚本任务.这样就足够了-并且在我看来肯定比java.io更亲切-但对于任何严重的I/O来说都不足够.对于Scala，有一个 real I/O库正在接受评估.

In the particular case of scala.io, that is not so much a library as a crude wrapper just to handle simple common scripting tasks with an idiomatic Scala API. It's adequate for that -- and certainly much kinder on my eyes than java.io --, but not for any serious I/O. There's a real I/O library for Scala currently undergoing evaluation for adoption.

另一个例子，如果scala.sys.process，我非常喜欢.它包装了Java的Process和ProcessBuilder，提供了几乎所有功能，并添加了一些功能.此外，如果需要，您可以使用大多数Java内部组件(唯一的例外是Process本身，实际上并没有太大用处.)

Another example I like a lot if scala.sys.process. It wraps over Java's Process and ProcessBuilder, providing almost all of the functionality, and adding some. Furthermore, you can use most of Java internals if needed (the sole exception is Process itself, which isn't really much useful).

我的建议是使用Scala库，只要它们存在并且可以满足您的需求，就可以扩展它们(如果它们足够用)，但是可以毫不犹豫地使用Java库.毕竟，与Java 的高度互操作性是Scala的主要功能.

My advice is to use Scala libraries were they exist and fit your needs, extend them if they are mostly adequate, but reach for Java libraries without hesitation otherwise. After all, having a high degree of interoperability with Java is a key feature of Scala.

这篇关于Java SE和Scala标准库-最好使用其中之一的情况的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！