在 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 时得到的堆栈跟踪。

`
线程 "main" 中发生异常 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 抛出

线程 "main" 中发生异常 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编译，这会递归地编译其依赖项，这些依赖项是大量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: 方法代码过大！"

0 票
由

评论者：alexmiller

我明白了。不过，我不确定有通用的方法可以检测这种情况并产生更好的错误。在Java中使用版本混合时，也可能出现类似的问题。

0 票
由

评论人：aroemers

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

然而，一种解决方案是将{{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 票
由
由 Cognitect 代表 Clojure 社区维护
...