小编Ale*_*ets的帖子

//API
class Node
class Person extends Node

object Finder
{
  def find[T <: Node](name: String): T = doFind(name).asInstanceOf[T]
}

//Call site (correct)
val person = find[Person]("joe")

//Call site (dies with a ClassCast inside b/c inferred type is Nothing)
val person = find("joe")

在上面的代码中,客户端站点"忘记"指定类型参数,因为API编写器我希望它意味着"只返回节点".有没有办法定义一个通用方法(而不是一个类)来实现这个(或等价).注意:在实现中使用清单来执行转换if(manifest!= scala.reflect.Manifest.Nothing)将无法编译...我有一种唠叨的感觉,一些Scala向导知道如何使用Predef.<:<为了这 :-)

想法？

给定了一个非常大的collection.parallel.mutable.ParHashMap(或任何其他并行集合)实例,如果找到一个给定的,比如50个匹配的数量,那么如何中止过滤并行扫描？

尝试在线程安全的"外部"数据结构中累积中间匹配或保持外部AtomicInteger的结果计数在4个内核上比使用常规collection.mutable.HashMap慢2到3倍,并将单个内核挂在100 %.

我知道Par*集合中的查找或存在确实在"内部"中止.有没有办法概括这个以找到多个结果？

下面是这似乎仍然是2至3倍慢上〜79,000项的ParHashMap的代码,也有馅的问题更比的maxResults(成果转化的结果CHM这可能是由于线程后被抢占incrementAndGet但在此之前突破这允许其他线程添加更多元素).更新:似乎减速是由于工作者线程在counter.incrementAndGet()上竞争,这当然违背了整个并行扫描的目的:-(

def find(filter: Node => Boolean, maxResults: Int): Iterable[Node] =
{
  val counter = new AtomicInteger(0)
  val results = new ConcurrentHashMap[Key,  Node](maxResults)

  import util.control.Breaks._

  breakable
  {
    for ((key, node) <- parHashMap if filter(node))
    {
      results.put(key, node)
      val total = counter.incrementAndGet()
      if (total > maxResults) break
    }
  }

  results.values.toArray(new Array[Node](results.size))
}

我想找到并重用(如果可能的话)具有以下属性的map实现:

1. 虽然条目数很少,比如<32,但是底层存储应该在这样的数组中完成[key0,val0,key1,val1,...]这种存储方案可以避免许多小的Entry对象并提供极快的查找速度(即使它们是顺序扫描!)在现代CPU上由于CPU的缓存未被无效以及缺少指针间接到堆中.

2. 无论与LinkedHashMap类似的条目数如何,映射都应保持键/值对的插入顺序

我们正在研究Scala中大量(数百万个节点/边缘)图形的内存表示,并且使用这样的Map可以让我们以更高效的方式存储节点/边缘属性以及每个节点的边缘,达到99%具有少量属性或邻居的节点和边缘的+,同时保留属性和边缘的按时间顺序的插入顺序.

如果有人知道具有这些特征的Scala或Java地图,我将非常感激不尽.

感谢名单

是否可以为本地运行的Java应用程序以及applet和/或JNLP webapps可靠地确定给定类的编译时间戳？

我们正在开发一个基于JavaCard的安全敏感应用程序.我们的目标是允许客户端代码与基于GlobaPlatform 2.2+的JavaCard applet进行通信,以使自己确信它实际上正在与需要与之交谈的JavaCard applet的特定(且可验证)版本进行通信.换句话说,我们正在寻找一种"平台完整性"机制,以确保JavaCard applet代码不可能由"内部人员"代替/修改(例如,即使是开发applet的我们).

起初我们希望使用GP规范中描述的安装收据机制,但我们被告知这不适用于该情况.

那么客户端代码是否有办法向卡片查询applet代码库(即安装的.cap文件)的真实性(例如简单哈希),而无需查询和信任JavaCard applet本身？