根据 SAM 类型扩展 FI（未标记为 FI）

Question

JDK 中有许多不是 FI 的 SAM 类型——一些显著的类型包括 Executor、ThreadFactory 等。增加我们要适应的范畴将使我们更接近 Java 的支持，并扩大可以使用此支持的范围。

简单示例

;; Adapt Thread constructor method value to ThreadFactory (not FI)
;; Use the factory to get a Thread with a Runnable and start it
(let [^java.util.concurrent.ThreadFactory tf ^[Runnable] Thread/new]
  (.start 
    (.newThread tf #(println "hi"))))

Execution error (ClassCastException) at user/eval145 (REPL:1).

class user$eval145$invoke__Thread_new__149 无法转换为 class java.util.concurrent.ThreadFactory

Jira: https://clojure.atlassian.net/browse/CLJ-2856

Comments

我曾问过 Brian Goetz 为什么 Java 中允许多种 SAM/SMI 在 lambda和方法引用中使用，而不仅仅是标记为 FunctionalInterface 的那些。令我惊讶的是，他回答说

问：为什么允许多种 SAM/SMI 在 lambda和方法引用中使用，不仅仅是标记为 FunctionalInterface 的那些？我认为这是这种脱节也导致了关于 FunctionalInterface 注解的混淆。至少对我来说，这个注解看起来是为了防止以未预见的方式使用未注解的接口，但实际上并不是这样。人们会想，如果我在 lambda 中还使用它，会怎么样呢？

布莱恩·戈茨：现有的Java库充满了SAM接口。要求在声明地点启用选择，意味着其他事情，比如，这些库在人们可以使用它们作为lambda目标之前必须更新。而且，没有任何合理的原因；所有这些都可以与单方法匿名类一起使用，而在这里不允许使用lambda只是出于限制本身。