在反射调用重载方法（Math/abs）时对原始类型的静默截断/向下转换

Question

我意识到在调用这些方法时依赖反射从性能上讲并不是一个好主意，但它不应导致不正确或有危险的行为。

在这里，这似乎触发了对输入长整型的静默向下转换，给出截断的整数输出

user> (defn f (link: a b) (Math/abs (- a b)))
反射警告，NO_SOURCE_PATH:1:15 - 无法解析对abs的调用。

'user/f

user> (f 1000000000000 2000000000000)
727379968
user> (class (f 1000000000000 2000000000000))
java.lang.Integer
user> (defn f (link: ^long a ^long b) (Math/abs (- a b)))

'user/f

user> (f 1000000000000 2000000000000)
1000000000000
user> (class (f 1000000000000 2000000000000))
java.lang.Long

Answer 1

评论由：matthjw

以下是复制问题的更简单的方法

user> (#(Math/abs %) 1000000000000)
反射警告，NO_SOURCE_PATH:1:3 - 无法解析对abs的调用。
727379968

Answer 2

评论由：jafingerhut

我能够在Ubuntu 12.04.2上的这些Java 6 JVM中复制你看到的行为

java版本 "1.6.0_27"
OpenJDK运行时环境（IcedTea6 1.12.5）(6b27-1.12.5-0ubuntu0.12.04.1)
OpenJDK 64位服务器虚拟机（构建20.0-b12，混合模式）

java版本 "1.6.0_45"
Java SE运行时环境（构建1.6.0_45-b06）
Java HotSpot 64位服务器虚拟机（构建20.45-b01，混合模式）

然而，我尝试了两个Java 7 JVM，它表现出以下行为，这看起来更接近你所期望的。我不知道Java 6和Java 7之间导致这种行为差异的精确区别，但这确实表明这与Java 6与Java 7有关。

user=> (set! warn-on-reflection true)
true
user=> (defn f (link: a b) (Math/abs (- a b)))
反射警告，NO_SOURCE_PATH:1:15 - 无法解析对abs的调用。

'user/f

user=> (f 1000000000000 2000000000000)
1000000000000
user=> (class (f 1000000000000 2000000000000))
java.lang.Long

在Clojure 1.5.1上观察到的上述行为

Ubuntu 12.04.2加上这个JVM
java版本 "1.7.0_21"
Java TM运行时环境（构建1.7.0 _ 21-b11)
Java HotSpot TM 64位服务器虚拟机（构建23.21-b01，混合模式)

Mac OS X 10.8.3加上这个JVM
java版本 "1.7.0_15"
Java TM运行时环境（构建1.7.0 _ 15-b03)
Java HotSpot TM 64位服务器虚拟机（构建23.7-b01，混合模式)

Answer 3

_Comment made by: matthjw_

Ah，有趣。
可能是在Java 7中，反射API工作的方式有所不同？

以下是生成的字节码，供有兴趣的人参考

public java.lang.Object invoke(java.lang.Object);
  代码
   0:     ldc     #14; //String java.lang.Math
   2:     invokestatic     #20; //Method java/lang/Class.forName:(Ljava/lang/String;)Ljava/lang/Class;
   5:     ldc     #22; //String abs
   7:     iconst_1
   8:     anewarray     #24; //class java/lang/Object
   11:     dup
   12:     iconst_0
   13:     aload_1
   14:     aconst_null
   15:     astore_1
   16:     aastore
   17:     invokestatic     #30; //Method clojure/lang/Reflector.invokeStaticMethod:(Ljava/lang/Class;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;
   20:     areturn

Answer 4

评论由：matthjw

这只是个想法（也许这正是Java 7中发生的事情？）但是鉴于它是一个静态方法并且所有可用的重载变体都可能在编译时已知，它可能生成以下类型的代码

(cond
(instance? Long x) (Math/abs (long x)))
(instance? Integer x) (Math/abs (int x)))
;; ...
)

Answer 5

评论由：jafingerhut

在Reflector.java方法中，调用getMethods()后调用invokeMatchingMethod()。getMethods()返回Java 6和Java 7中的不同的排序的4个java.lang.Math/abs方法，导致在两个JVM上选择不同的方法。

Java版本 "1.6.0_39"
Java(TM) SE运行时环境（构建1.6.0_39-b04）
Java HotSpot(TM) 64位服务器虚拟机（构建20.14-b01，混合模式）

用户=> (pprint (seq (clojure.lang.Reflector/getMethods java.lang.Math 1 "abs" true)))
(#
#
#
#)
nil

java版本 "1.7.0_21"
Java TM运行时环境（构建1.7.0 _ 21-b11)
Java HotSpot TM 64位服务器虚拟机（构建23.21-b01，混合模式)

用户=> (pprint (seq (clojure.lang.Reflector/getMethods java.lang.Math 1 "abs" true)))
(#
#
#
#)
nil

这可能表明invokeMatchingMethod()方法在调用时过于依赖给定方法的顺序，可能是不可取的行为。

正如你提到的，类型提示能够有效避免反射带来的显著性能损耗。

Answer 6

评论者：alexmiller

在1.8.0-alpha3版本上无法重现。

Answer 7

评论者：bronsa

亚历克斯，我使用1.8.0-master-SNAPSHOT和jdk 1.8能够重现。

[~]> java -version java version "1.8.0_45" Java(TM) SE运行时环境（构建1.8.0_45-b14） Java HotSpot(TM) 64位服务器虚拟机（构建25.45-b02，混合模式） [~]> clj Clojure 1.8.0-master-SNAPSHOT 用户=> (set! *warn-on-reflection* true) 真诚的用户=> (#(Math/abs %) 1000000000000) 反射警告，NO_SOURCE_PATH:2:3 - 调用java.lang.Math的静态方法abs无法解析（参数727379968 用户=> (class *1) java.lang.Integer

安迪最后一条评论提到达成clojure.lang.Reflector.invokeStaticMethod依赖于传递给它的方法顺序，并且这个顺序可能在不同的jdk版本之间发生变化，这可能是你无法重现的原因。

Answer 8

评论由：jafingerhut

可能与CLJ-1921相同，或者至少有一些共同点。

Answer 9

参考：https://clojure.atlassian.net/browse/CLJ-1212（由ale+import报告）