请在 2024 Clojure 状态调查！ 中分享您的想法。

欢迎！请查阅 关于 页面以获取更多关于如何使用本站的信息。

提问问题

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

0 票
在 编译器 由

在我不太理解的一些特定情况下，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

`

11 答案

0 票
由

评论人：hiredman

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

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

并且无法编译所需的 Java 源文件

编辑：它可以编译 Java 源文件，但不会为 Clojure 创建默认的编译器输出目录，也不会创建它

0 票
由

评论人：hiredman

对于从 GitHub 项目检出并使用 lein compile 编译的项目，我没有出现错误

0 票
由

评论人：hiredman

稍微调整了一下，许多依赖及其瞬态依赖似乎已经进行了AOT编译，这很可能使用了不同的Clojure版本，但据我所知，这并不是预期的。使用Clojure版本A编译的代码与使用Clojure版本B编译的代码无法链接。

0 票
由

评论者：bronsa

我同意Kevin的看法。问题是高度可能的，是由依赖被分配为AOT以及依赖冲突造成的。

0 票
由

评论人：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编译的，所以所有东西都崩溃了。

0 票
由

评论者：alexmiller

发布带有AOT编译依赖项的jar文件确实是一个问题。我意识到这可能会因为CLJ-322（我希望今年能在这个问题上有一些进展）而变得有点痛苦。

这个工单上还需要做些什么其他的事情吗？

0 票
由

评论者：bronsa

我认为我们除了推动CLJ-322之外，别无他法；另一方面，我们不鼓励用户发布AOT编译的库。

0 票
由

评论者：ryfow

对我来说，问题是错误信息。虽然我不能依赖AOT编译的库，但是当我这样做时，错误信息为“java.lang.NoSuchFieldError: thunk0__”或“java.lang.RuntimeException: Method code too large!”似乎不太对。

0 票
由

评论者：alexmiller

我理解你的观点。不幸的是，我不确定是否有通用的方法来检测这种情况，并产生更好的错误。在Java中使用不同版本的库混合时，也可能会发生类似的问题。

0 票
由

评论者：aroemers

我不确定这个问题仅仅是因为有一个AOT编译库。我开始重写slf4j-timbre库的部分，以去除对AOT的需求（链接：1）。但我在那个版本中发现，当在编译期间TimbreLoggerAdapter加载slf4j-timbre.adapter命名空间，而不是Clojure命名空间时，问题仍然存在。因此，当在编译期间执行SLF4J日志语句时，运行结果仍然会遇到 problème avec __thunk__。

但是一种解决方案是将 {{require}} {{slf4j-timbre.adapter}} 命名空间作为AOT编译命名空间中的第一个之一。这对于slf4j-timbre库的当前AOT编译版本也有效。因此，解决此问题可能更多地与AOT编译期间通过Java类进行命名空间递归加载有关，而不是与AOT编译库本身有关？

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

0 票
由
参考资料： https://clojure.atlassian.net/browse/CLJ-1886 （由ryfow报告）
由Cognitect代表Clojure社区维护
...