2024年Clojure状态调查!中分享您的想法。

欢迎!请参阅关于页面以获取更多关于如何使用此页面的信息。

0
提出 Clojure

此错误的最为明显的症状是在您的classpath中有一个名为'w'(默认包)的类(由yFiles等Java混淆工具生成的此类类)并在尝试加载Clojure的core类。例如

java -cp hotspotapi.jar:clojure-1.4.0-slim.jar clojure.main

(其中hotspotapi.jar是混淆JAR的一个典型例子)会产生以下结果

线程 "main" 中发生异常:java.lang.ExceptionInInitializerError

at clojure.main.<clinit>(main.java:20)

原因:java.lang.NoSuchFieldException: close,编译:(clojure/core.clj:6139)

at clojure.lang.Compiler.analyzeSeq(Compiler.java:6462)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$TryExpr$Parser.parse(Compiler.java:2178)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:5919)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5618)
at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5054)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3674)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6453)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6443)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.access$100(Compiler.java:37)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:518)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
at clojure.lang.Compiler.analyze(Compiler.java:6262)
at clojure.lang.Compiler.analyze(Compiler.java:6223)
at clojure.lang.Compiler.eval(Compiler.java:6515)
at clojure.lang.Compiler.load(Compiler.java:6952)
at clojure.lang.RT.loadResourceScript(RT.java:359)
at clojure.lang.RT.loadResourceScript(RT.java:350)
at clojure.lang.RT.load(RT.java:429)
at clojure.lang.RT.load(RT.java:400)
at clojure.lang.RT.doInit(RT.java:436)
at clojure.lang.RT.<clinit>(RT.java:318)
... 1 more

原因:java.lang.NoSuchFieldException: close

at java.lang.Class.getField(Class.java:1537)
at clojure.lang.Compiler$StaticFieldExpr.<init>(Compiler.java:1180)
at clojure.lang.Compiler$HostExpr$Parser.parse(Compiler.java:923)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:6455)
... 37 more

找不到主类:clojure.main。程序将退出。

为了理解发生了什么,考虑这个简单的测试

import java.io.StringReader;

import clojure.lang.Compiler;
import clojure.lang.RT;

public class Test {

public static void main(String(link: ) args) {
    RT.var("clojure.core", "require");
    String s = "(let (link: mumble (new java.io.StringReader \"\")) (. mumble close))";
    Compiler.load(new StringReader(s));
}

}

在点操作符的'mumble'应该明确地引用局部定义的mumble。然而,如果我们定义一个名为'mumble'的类在默认包中,Clojure将选择那个。

为了避免任何反对意见:是的,我们知道将类放在默认包中是非常糟糕的风格。然而,Java生态系统非常多样化,有许多JAR包人们无法控制。虽然有人可能会争论,"不要在默认命名空间中放类",但关键是,Clojure在这里是错误的,并且这些情况在现实中确实出现,并非由于实现者的错误。

5 个回答

0
回答

由ezyang发表的评论

这里是一个修补程序,可以让这个错误不太可能发生。

0
by

评论者:jafingerhut

Edward,Rich Hickey的政策是只考虑将那些签署了贡献协议的人编写的补丁代码包含在Clojure补丁中:https://clojure.org/contributing

您有兴趣成为贡献者吗?

0
by

由ezyang发表的评论

当然,虽然附带的补丁远远不是你想要实际应用的,因为它的作用仅仅是临时补救问题。

0
by

评论者:jafingerhut

我不确定,但这个工单可能与CLJ-1171有关。至少在那里,问题是一个全局名称 不是 被let绑定的一个局部名称所掩盖。这似乎与这个问题很相似。

0
by
参考: https://clojure.atlassian.net/browse/CLJ-1016 (由 ezyang 报告)
...