在编译时实体对象不满足协议

Question

https://github.com/MichaelBlume/reify-fail

`
(defprotocol Foo
(hello [this] "Says hello"))

(def bar
(reify Foo

(hello [this] "hello, world")))

(when-not (satisfies? Foo bar)
(throw (Exception. "bar doesn't satisfy Foo")))
`

备注

项目是 AOT（Ahead-Of-Time 编译）
另一个命名空间需要此命名空间。该命名空间首先被编译。如果没有那个命名空间，问题就消失了。

Answer 1

评论者：hiredman

在检出代码仓库后，您采取了哪些步骤来重现此问题？

我克隆了仓库并运行lein compile，但没有出错。

Answer 2

评论者：michaelblume

我用lein check尝试重现这个问题，但是lein compile也失败了，所以我有点困惑。

Answer 3

评论者：michaelblume

我认为非常重要的一点是，接近空白的命名空间应该先编译，可能编译顺序的平台有差异？

Answer 4

评论者：michaelblume

在macOS和Ubuntu上测试代码仓库均失败，两个操作系统都使用了Java 8

Answer 5

评论者：michaelblume

在Ubuntu上我有

$ lein -v
Leiningen 2.7.1 with Java 1.8.0_151 OpenJDK 64-Bit Server VM

Answer 6

_评论者：jafingerhut_

在这两个操作系统上：Ubuntu 16.04.3 Linux，macOS 10.12.6

在这两个Leiningen版本上：2.7.1，2.8.1

我相信所有实验都使用了最近的JDK 1.8版本

对于以下任一Clojure版本：1.7.0 1.8.0 1.9.0

在使用项目https://github.com/MichaelBlume/reify-fail,的'lein check'和'lein compile'命令下，我都会遇到错误，但只有在我首先运行'/bin/rm -fr target'命令（或者在目标目录创建之前运行它，例如在运行'git clone'命令@Repository后立即运行）时才会发生这 种情况。

如果运行该命令两次，第一个命令会在目标目录中创建许多.class文件，而第二个这样的命令不会产生错误。

Answer 7

评论者：hiredman

如果我用:aot:all替换为:aot(link: com.lendup.citadel.pipeline com.lendup.citadel.providers.mocky)，我就可以重现这个错误。我怀疑lein可以在编译命名空间之间进行旧的ns检查来避免重复编译迁移命名空间。

Answer 8

评论者：hiredman

可能与https://github.com/technomancy/leiningen/issues/2316有关

Answer 9

评论由：ikitommi 发布

相关链接：https://github.com/technomancy/leiningen/issues/2508。

Answer 10

评论由：bronsa 发布

这是Clojure还是Lein问题？我们能否通过裸 clj 代码来重现这个问题？

Answer 11

评论由：alexmiller 发布

我怀疑你可以通过按照特定顺序编译某些东西来重现这个问题，但我还没有尝试过。但最终的答案可能是：按正确的顺序编译。

Answer 12

参考：[https://clojure.atlassian.net/browse/CLJ-2303](https://clojure.atlassian.net/browse/CLJ-2303)（由michaelblume报告）