以 `com` 开头的命名空间在 graaljs replenv 中损坏

Question

安装了 graal


$ java -version
openjdk 版本 "1.8.0_212"
OpenJDK 运行时环境（构建 1.8.0_212-20190420112649.buildslave.jdk8u-src-tar--b03)
OpenJDK GraalVM CE 19.0.0（构建 25.212-b03-jvmci-19-b01，混合模式）



$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.520"}}}' -m cljs.main -re graaljs
ClojureScript 1.10.520
cljs.user=> (ns com.foo)

com.foo=> (defn bar [])
#'com.foo/bar
com.foo=> (bar)
执行错误（错误）在 (<cljs repl>:1)。
(中间值).foo.bar.call 不是一个函数

Answer 1

评论者：kommen

GraalJS 问题：https://github.com/graalvm/graaljs/issues/164

Answer 2

评论者：mfikes

让我想起了 CLJS-2770

Answer 3

评论者：mfikes

我想知道将 {{js.java-package-globals}} 设置为禁用它们是否足以处理此问题，或者这会引入其他问题


使用以下命令启动 ClojureScript REPL，包含 GraalJS 引擎和禁用 JavaScript 全局对象的默认设置：$ clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.520"}}}' -m cljs.main -re graaljs -ro '{"js.java-package-globals" "false"}' -r
ClojureScript 1.10.520
cljs.user=> (ns com.foo)

com.foo=> (defn bar [])
#'com.foo/bar
com.foo=> (bar)
nil


有关 GraalJS REPL 选项的详细信息，请参阅https://script.clojure.org/reference/repl-options#_graal_js_repl_options

Answer 4

评论者：kommen

使用 {{js.java-package-globals}} 也可以解决这个问题。由于现在提供了更多的“顶级域名”（如 Packages、java、javafx、javax、com、org、edu），这将解决对这些域名的使用。正如 Mike 指出的，但这也将是一个破坏性变更，因为当某人在 Graal 环境中运行时可能会依赖于这些全局变量。

Answer 5

评论者：kommen

CLJS-3087-2.patch 默认关闭 Java 包全局设置。

我更喜欢与其他 JavaScript 引擎以及 GraalJS 上运行的 Clojure 和 ClojureScript 之间的兼容性，而不是让 Java 包全局可用作为一个便捷方式。使用 {{Java.type}} 作为 (link: https://github.com/clojure/clojurescript/blob/3a0c07477ae781bf521bdc2b074ed7b783bb93f3/src/main/cljs/cljs/bootstrap_graaljs.js#L4 文本：graaljs_load) 中使用的功能仍然可用。

Answer 6

评论者：mfikes

尽管这是一个破坏性变更，但由于 GraalJS 并非全新发布，因此不太可能破坏任何人。如果确实如此，可以覆盖默认设置。

(link: ~kommen) 您指出在这里看到了 Java 包的使用：https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1672-L1676

我没有检查过，如果我们将默认值进行修订，这些会受到什么影响？

Answer 7

评论者：kommen

(link: ~mfikes) 根据我所见，更改默认选项不会影响这些，因为使用默认选项创建的 GraalJS 引擎不会用于运行由 {{output-main-file}} 产生的工件。但我仍然建议将这些使用更改为使用 {{Java.type}}（待与 Nashorn 兼容），这样就可以使用启用了 {{js.java-package-globals}} 的关闭的 GraalJS 命令行工具，并仍然能够让生成的主文件正常工作。

Answer 8

评论者：mfikes

CLJS-3087-2.patch 通过了CI测试

Answer 9

评论者：mfikes

CLJS-3087-2.patch 已添加到补丁库

Answer 10

评论者：mfikes

CLJS-3087-2.patch LGTM (y)

Answer 11

评论者：kommen

在graaljs issues(链接: https://github.com/graalvm/graaljs/issues/164)中，他们不打算修改{{js.java-package-globals}}的默认值，因此虽然CLJS-3087-2.patch会修复GraalJS repl的问题，但人们仍然需要在使用{{js}}或{{nodejs}}命令行工具时了解需要将其关闭。

Answer 12

_由 kommen_发表的评论

一个真实世界的遇到此问题的示例



clj -Sdeps '{:deps {org.clojure/clojurescript {:mvn/version "1.10.520"} com.cognitect/transit-cljs {:mvn/version "0.8.256"}}}' -m cljs.main -re graaljs
ClojureScript 1.10.520
cljs.user=> (require '[cognitect.transit :as t])
执行错误 ()，在 (<cljs repl>:1)
null

Answer 13

由 dnolen 发表的评论

迪特尔，我不明白你关于js和nodejs的最后一次评论。它们如何受到影响？

Answer 14

由 dnolen 发表的评论

我倾向于选择第二个补丁，该补丁禁用了隐式全局导入。无论如何都依赖它是一件令人厌恶的事情......但是对于另一个票据——但是我们想知道是否应该有对Java包的支持require。

Answer 15

评论者：kommen

(链接：~dnolen) GraalVM 随附了 {{bin/js}} 和 {{bin/nodejs}} 二进制文件，两者都使用 GraalJS 引擎，但默认将 {{js.java-package-globals}} 设置为 {{true}}。因此，如果使用 GraalVM 的 {{nodejs}} 运行 ClojureScript工件，仍会遇到一个具有问题前缀的命名空间问题。当然，这超出了 ClojureScript 的控制范围，但我认为它对补丁提供了一个不同的视角，因为该补丁并没有涵盖所有可能导致此问题的路径。