以 `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)
执行错误（错误）在 （：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}} 设置为禁用它们是否足够，或者是否会导致其他问题


$ 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


请参阅https://script.clojure.org/reference/repl-options#_graal_js_repl_options

Answer 4

评论由：kommen 提出

使用 {{js.java-package-globals}} 也能解决问题，并且由于提供了更多的 "tlds"（如 Packages、java、javafx、javax、com、org、edu），这将解决对这些的使用的相应问题。正如Mike指出，这将是一个破坏性的变化，因为在运行在graal环境中的某个依赖这些全局变量的情况下。

Answer 5

评论由：kommen 提出

CLJS-3087-2.patch 默认关闭 java 包全局变量。

我更倾向于Clojure和ClojureScript在GraalJS上的兼容性，而不是java包全局变量作为捷径。功能仍然可以通过 {{Java.type}} 获取，见https://github.com/clojure/clojurescript/blob/3a0c07477ae781bf521bdc2b074ed7b783bb93f3/src/main/cljs/cljs/bootstrap_graaljs.js#L4文本：graaljs_load。

Answer 6

评论由：mfikes 提出

尽管这从严格意义上来说是一个破坏性的变化，但GraalJS还没有推出那么长时间，所以这样的变化不大可能破坏任何人。如果真的破坏了，可以覆盖默认设置。

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L1672-L1676中看到你指出这里使用Java包。

我没有查看，如果修改默认设置，它们是否会受到影响？

Answer 7

评论由：kommen 提出

(link: ~mfikes) 如我所见，这些变更不会影响默认选项，因为使用默认选项创建的GraalJS引擎不会用于运行由{{output-main-file}}生成的工件。但我仍然建议将这些用法改为使用{{Java.type}}（待Nashorn兼容性），这样就可以在不具有{{js.java-package-globals}}的情况下使用GraalJS的{{js}}命令行工具，并且仍然可以使得产出主文件工作。

Answer 8

评论由：mfikes 提出

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

Answer 9

评论由：mfikes 提出

CLJS-3087-2.patch 添加到补丁提案（i）

Answer 10

评论由：mfikes 提出

CLJS-3087-2.patch LGTM（y）

Answer 11

评论由：kommen 提出

在graaljs问题（链接：https://github.com/graalvm/graaljs/issues/164 文本：graaljs问题）所在的地点，他们并不打算改变{{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 的控制范围，但我认为这为补丁提供了另一个视角，因为补丁并没有涵盖所有可能导致此问题的路径。