JavaConverters asScala 方法的时间复杂度

发布于 2024-12-21 06:02:07 字数 348 浏览 1 评论 0原文

从 Scala 2.9 版本开始，存在一个方便的转换器，可以通过编写如下内容将 java.util.List 和其他集合转换为 Scala 的数据结构：

import scala.collection.JavaConverters._
def scalaVersion = callJavaMethod.asScala

这是一个可爱的小功能，因为它允许人们与现有 Java 代码交互时利用 Scala 的优势。

但是，我不确定所涉及的时间和空间复杂度，并且在官方文档中找不到任何内容，因此，出现以下问题：

在哪里可以获得有关JavaConverters的复杂度（时间和空间）的信息？

原文

Starting with Scala version 2.9 there exists a handy converter to convert from java.util.List and other collections to Scala's data structures by writing something like this:

import scala.collection.JavaConverters._
def scalaVersion = callJavaMethod.asScala

This is a lovely little feature, as it allows one to exploit the advantages of Scala when interacting with existing Java code.

However, I am uncertain about the involved time and space complexity and could not find anything in the official documentation, hence, the following question:

Where can I get information on the complexity (time and space) of the JavaConverters?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

胡渣熟男 2024-12-28 06:02:07

各种 JavaConverters 类使用 Adapter 模式包装原始Java集合（底层）并提供Scala接口。因此，转换和访问转换后的集合在时间上都是恒定的 (O(1))，仅引入很小的开销。

例如，这是 < 的完整源代码code>JListWrapper：

case class JListWrapper[A](val underlying : java.util.List[A]) extends mutable.Buffer[A] {
    def length = underlying.size
    override def isEmpty = underlying.isEmpty
    override def iterator : Iterator[A] = underlying.iterator
    def apply(i : Int) = underlying.get(i)
    def update(i : Int, elem : A) = underlying.set(i, elem)
    def +=:(elem : A) = { underlying.subList(0, 0).add(elem) ; this } 
    def +=(elem : A): this.type = { underlying.add(elem); this }
    def insertAll(i : Int, elems : Traversable[A]) = { val ins = underlying.subList(0, i) ;  elems.seq.foreach(ins.add(_)) }
    def remove(i : Int) = underlying.remove(i)
    def clear = underlying.clear
    def result = this
}

另请注意，将 Java 集合转换为 Scala，然后再转换回 Java 会生成原始集合，而不是双重包装器。

Various JavaConverters classes are using Adapter pattern to wrap original Java collection (underlying) and provide Scala interface. Thus both converting and accessing converted collections is constant in time (O(1)) introducing only minor overhead.

For instance this is the full source code of JListWrapper:

case class JListWrapper[A](val underlying : java.util.List[A]) extends mutable.Buffer[A] {
    def length = underlying.size
    override def isEmpty = underlying.isEmpty
    override def iterator : Iterator[A] = underlying.iterator
    def apply(i : Int) = underlying.get(i)
    def update(i : Int, elem : A) = underlying.set(i, elem)
    def +=:(elem : A) = { underlying.subList(0, 0).add(elem) ; this } 
    def +=(elem : A): this.type = { underlying.add(elem); this }
    def insertAll(i : Int, elems : Traversable[A]) = { val ins = underlying.subList(0, i) ;  elems.seq.foreach(ins.add(_)) }
    def remove(i : Int) = underlying.remove(i)
    def clear = underlying.clear
    def result = this
}

Also note that converting Java collection to Scala and then back to Java yields the original collection, not double-wrapper.

回复收藏 0 原文

~没有更多了~