AOT编译可能导致java.lang.NoSuchFieldError: __thunk__0__

Question

在我不了解的一些特定情况下，AOT编译器可以创建具有对名为thunk0__字段的矛盾想法的类文件。

我在https://github.com/ryfow/weird-aot上创建了一个项目，该项目通过执行lein run重现了问题。

重现问题的要素似乎是slf4j-timbre、tools.analyzer和core.async。

我认为slf4j-timbre已被AOT编译但不是由Clojure代码直接加载，这是一个因素。

注意：weird-aot项目中的timbre版本与slf4j-timbre编译的版本不同。

我不清楚为什么需要tools.analyzer和core.async来展示这个问题。

下面是我运行weird-aot项目中的lein run时得到的堆栈跟踪。

`
主线程中发生异常java.lang.NoSuchFieldError: thunk0__，编译：（/private/var/folders/2q/tk7cywk93217_d4pxn_5kft40000gn/T/form-init7490372454812250103.clj：1：125）

    at clojure.lang.Compiler.load(Compiler.java:7239)
    at clojure.lang.Compiler.loadFile(Compiler.java:7165)
    at clojure.main$load_script.invoke(main.clj:275)
    at clojure.main$init_opt.invoke(main.clj:280)
    at clojure.main$initialize.invoke(main.clj:308)
    at clojure.main$null_opt.invoke(main.clj:343)
    at clojure.main$main.doInvoke(main.clj:421)
    at clojure.lang.RestFn.invoke(RestFn.java:421)
    at clojure.lang.Var.invoke(Var.java:383)
    at clojure.lang.AFn.applyToHelper(AFn.java:156)
    at clojure.lang.Var.applyTo(Var.java:700)
    at clojure.main.main(main.java:37)

原因是java.lang.NoSuchFieldError: thunk0__

    at clojure.tools.analyzer.jvm.utils__init.load(Unknown Source)
    at clojure.tools.analyzer.jvm.utils__init.<clinit>(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:340)
    at clojure.lang.RT.classForName(RT.java:2154)
    at clojure.lang.RT.classForName(RT.java:2163)
    at clojure.lang.RT.loadClassForName(RT.java:2182)
    at clojure.lang.RT.load(RT.java:436)
    at clojure.lang.RT.load(RT.java:412)
    at clojure.core$load$fn__5448.invoke(core.clj:5866)
    at clojure.core$load.doInvoke(core.clj:5865)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.core$load_one.invoke(core.clj:5671)
    at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
    at clojure.core$load_lib.doInvoke(core.clj:5710)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$load_libs.doInvoke(core.clj:5749)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$require.doInvoke(core.clj:5832)
    at clojure.lang.RestFn.invoke(RestFn.java:703)
    at clojure.tools.analyzer.jvm$loading__5340__auto____1677.invoke(jvm.clj:9)
    at clojure.tools.analyzer.jvm__init.load(Unknown Source)
    at clojure.tools.analyzer.jvm__init.<clinit>(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:340)
    at clojure.lang.RT.classForName(RT.java:2154)
    at clojure.lang.RT.classForName(RT.java:2163)
    at clojure.lang.RT.loadClassForName(RT.java:2182)
    at clojure.lang.RT.load(RT.java:436)
    at clojure.lang.RT.load(RT.java:412)
    at clojure.core$load$fn__5448.invoke(core.clj:5866)
    at clojure.core$load.doInvoke(core.clj:5865)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.core$load_one.invoke(core.clj:5671)
    at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
    at clojure.core$load_lib.doInvoke(core.clj:5710)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$load_libs.doInvoke(core.clj:5749)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$require.doInvoke(core.clj:5832)
    at clojure.lang.RestFn.invoke(RestFn.java:421)
    at weird_aot.core$loading__5340__auto____81.invoke(core.clj:1)
    at weird_aot.core__init.load(Unknown Source)
    at weird_aot.core__init.<clinit>(Unknown Source)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:340)
    at clojure.lang.RT.classForName(RT.java:2154)
    at clojure.lang.RT.classForName(RT.java:2163)
    at clojure.lang.RT.loadClassForName(RT.java:2182)
    at clojure.lang.RT.load(RT.java:436)
    at clojure.lang.RT.load(RT.java:412)
    at clojure.core$load$fn__5448.invoke(core.clj:5866)
    at clojure.core$load.doInvoke(core.clj:5865)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.core$load_one.invoke(core.clj:5671)
    at clojure.core$load_lib$fn__5397.invoke(core.clj:5711)
    at clojure.core$load_lib.doInvoke(core.clj:5710)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$load_libs.doInvoke(core.clj:5749)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:632)
    at clojure.core$require.doInvoke(core.clj:5832)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at user$eval65$fn__67.invoke(form-init7490372454812250103.clj:1)
    at user$eval65.invoke(form-init7490372454812250103.clj:1)
    at clojure.lang.Compiler.eval(Compiler.java:6782)
    at clojure.lang.Compiler.eval(Compiler.java:6772)
    at clojure.lang.Compiler.load(Compiler.java:7227)
    ... 11 more

`

Answer 1

评论由：hiredman发布

在链接的GitHub仓库中抛出run.sh异常

主线程中发生异常java.lang.RuntimeException：方法代码过大！，编译：（weird_aot/jetty.clj：4：1）

并且无法编译所需的Java源代码

编辑它确实编译了Java源代码，但未创建Clojure的默认编译器输出目录，或者创建了

Answer 2

评论由：hiredman发布

使用已签出的链接GitHub项目运行lein compile对我没有错误完成

Answer 3

评论由：hiredman发布

稍作修改，发现一些依赖及其瞬态依赖似乎是AOT编译的，可能是使用不同版本的Clojure完成的，据我所知这与预期不符。使用Clojure版本A编译的aot代码将无法与使用Clojure版本B编译的代码链接

Answer 4

评论者：bronsa

我同意Kevin的看法。这个问题很可能是由于依赖项以AOT形式分发以及依赖冲突引起的。

Answer 5

评论由：hiredman发布

com.fzakaria/slf4j-timbre "0.2.2"存在问题。该库是AOT编译的，它递归地AOT编译其依赖项，这些依赖项是多个timbre库的旧版本，这些库反过来又依赖于旧版本的tools.reader，因此com.fzakaria/slf4j-timbre "0.2.2"的jar文件中包含了一个旧的tools.reader编译版本。org.clojure/tools.analyzer.jvm "0.6.9"是与较新版本的tools.reader AOT编译的，因此所有东西都崩溃了

Answer 6

评论者：alexmiller

发布带有AOT依赖项的jar文件肯定是个问题。我意识到这有点痛苦，因为CLJ-322（我希望在今年真正取得一些进展）。

关于这个票据还有其他需要做的事情吗？

Answer 7

评论者：bronsa

我认为我们无法做的只有推动CLJ-322并劝阻用户发布AOT编译库

Answer 8

评论由：ryfow发表

对我来说，问题是错误信息。我不能依赖于AOT编译的库倒是没关系。但是，当我这样做时，错误信息是 "java.lang.NoSuchFieldError: thunk0__" 或 "java.lang.RuntimeException: 方法代码太大！" 就不太好了。

Answer 9

评论者：alexmiller

我理解你的意思。不幸的是，我并不知道有通用的方法可以检测这种情况并产生更好的错误信息。当使用不同版本的库时，Java也会发生类似的问题。

Answer 10

评论由：aroemers发表

我不确定问题是不是（仅仅）由于有AOT编译的库引起的。我开始重新编写slf4j-timbre库的部分代码，以便去除对AOT的需求（链接：1）。但是，我发现即使在编译期间，当{{TimbreLoggerAdapter}}加载{{slf4j-timbre(adapter)}}命名空间时，而不是一个Clojure命名空间，问题仍然存在。所以，当我们进行SLF4J日志语句时，在编译过程中仍然会遭遇__thunk__问题。

然而，一个解决方案是在AOT编译的命名空间之一中{{require}}{{slf4j-timbre(adapter)}}命名空间。这也适用于当前slf4j-timbre库的AOT编译版本。所以，也许解决这个问题的方法与在AOT编译期间通过Java类进行命名空间递归加载有关，而不仅仅是与AOT编译库本身有关？

(链接：1) https://github.com/hellodata-org/slf4j-timbre/blob/f9a2f4469fd92063c261276479593de39fffbee3/src-java/com/github/fzakaria/slf4j/TimbreLoggerAdapter.java

Answer 11

参考资料：https://clojure.atlassian.net/browse/CLJ-1886（由ryfow报告）