如何在纯Scala中表示盒装双精度?

如何在纯Scala中表示盒装双精度?,scala,autoboxing,Scala,Autoboxing,在Scala中,双精度数字有两种表示形式,一种是AnyVal,另一种是AnyRef。在JVM上,它们分别映射到原语double和类java.lang.double 现在,在JVM以外的平台上会发生什么?我可以对原语使用Scala.Double,但是如何在不指定java.lang.Double的情况下指定对已装箱的Double的引用 [背景-留下来理解托马斯的答案,但不是根本问题 我有一个我想用Spring注入Wicket组件的Double: class MyPanel(id: String)

在Scala中,双精度数字有两种表示形式,一种是
AnyVal
,另一种是
AnyRef
。在JVM上,它们分别映射到原语
double
和类
java.lang.double

现在,在JVM以外的平台上会发生什么?我可以对原语使用
Scala.Double
,但是如何在不指定
java.lang.Double
的情况下指定对已装箱的Double的引用


[背景-留下来理解托马斯的答案,但不是根本问题

我有一个我想用Spring注入Wicket组件的Double:

class MyPanel(id: String) extends Panel(id) {
  @SpringBean(name="rxAlarmLimitDb") var alarmLimitDb: Double = _
如果我如上所述将类型指定为
scala.Double
,则注入器将失败,因为它只能注入对象

如果我指定
java.lang.Double
作为字段的类型,则一切正常

class MyPanel(id: String) extends Panel(id) {
  @SpringBean(name="rxAlarmLimitDb") var alarmLimitDb: java.lang.Double = _
但是我试图减少对Java API的依赖,那么如果没有它,我如何表示装箱的
Double

]为什么不创建一个scala.Double类型的bean呢?很糟糕,但似乎它起作用了:

<bean id="rxAlarmLimitDb" class="scala.Double" factory-method="unbox">
    <constructor-arg>
        <bean class="java.lang.Double">
            <constructor-arg value="4.2"/>
        </bean>
    </constructor-arg>
</bean>


scala.Double
=
Double
在Java中。当您将一个
scala.Double
框起来时,它将变成一个
java.lang.Double

scala> val f = 45d;
f: Double = 45.0

scala> println("f=" + f.getClass)
f=double

scala> def foo(d: Any) = println("d=" + d.getClass)
foo: (d: Any)Unit

scala> foo(f)
d=class java.lang.Double
没有任何方法可以创建类型为
scala.Double
的对象。这只是double的别名。因此,对于您的问题,您需要使用
java.lang.Double
,或者将其包含在您自己的类型中并提供隐式转换

如果你仔细想想,这个定义是有道理的。java和scala代码之间需要自动装箱和取消装箱的所有交互都将按预期工作

如果有什么不同,您可以随时执行以下操作:

type BoxedDouble = java.lang.Double

那么您就不必看到java.lang:-)

我猜装箱的double是
java.lang.double
——就像Scala使用java类处理很多其他事情一样(AnyRef=java.lang.Object,String=java.lang.String)。不过,我不确定。这些语句在JVM上是正确的。在CLR上有不同的映射,我想知道如何在其中一个上表示盒装双精度。@Duncan你能把它作为问题的一部分吗?或者更好地创建一个新的。因为在CLR上运行Spring会有它自己的问题。我编辑这个问题是为了明确(呃)这不是关于Spring的问题,而是关于Scala类型系统的问题。我想我的问题是通过java.Lang.Double解决的——但我很好奇!所有这些语句在JVM上都是正确的,但Scala针对的是其他环境。从我的观点来看,关于创建类型别名的最后一节解决了@DuncanMcGregor的问题。