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

Question

安装 graal 后


$ java -version
openjdk 版本 "1.8.0_212"
OpenJDK Runtime Environment (构建 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_

我 wonder if setting {{js.java-package-globals}} to disable them is sufficient for this case, or if that brings in other issues


$ 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}}也能解决问题，因为提供了更多的“顶级域名”（如： Packages, java, javafx, javax, com, org, edu），这也会修复对这些域的使用。正如Mike所说，这会被视为一个破坏性变更，因为有人在Graal env中运行时依赖于这些全局变量。

Answer 5

评论者：kommen

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

我更倾向于与其他JS引擎以及GraalJS上运行的Clojure和ClojureScript之间的兼容性，而不仅仅是将java包的全局变量作为快捷方式提供。功能仍然可以通过（链接：https://github.com/clojure/clojurescript/blob/3a0c07477ae781bf521bdc2b074ed7b783bb93f3/src/main/cljs/cljs/bootstrap_graaljs.js#L4文本：graaljs_load）中的{{Java.type}}来实现。

Answer 6

评论者：mfikes

尽管这严格来说是一个破坏性变更，但GraalJS还不是很普及，因此这样的变更不太可能破坏任何人。如果是这样的话，仍然可以覆盖默认设置。

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

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

Answer 7

评论者：kommen

(链接：~mfikes) 根据我所见，默认选项的更改不会影响这些变量，因为使用默认选项创建的GraalJS引擎不会用于运行{{output-main-file}}生成的构件。但我仍建议将这些用法改为使用{{Java.type}}，以便可以使用关闭{{js.java-package-globals}}的GraalJS {{js}}命令行工具，同时保证生成的main文件仍然可用。

Answer 8

评论者：mfikes

CLJS-3087-2.patch通过CI测试 (//)

Answer 9

评论者：mfikes

CLJS-3087-2.patch已添加到补丁竞标 (i)

Answer 10

评论者：mfikes

CLJS-3087-2.patch LGTM (好的)

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

我倾向于第二个补丁，该补丁禁用了隐式全局导入。这样做本身就是一件很糟糕的事情...但对于另一个ticket来说也是如此...但我好奇我们是否应该为Java包提供require支持。

Answer 15

评论者：kommen

(链接: ~dnolen) GraalVM捆绑了{{bin/js}}和{{bin/nodejs}}二进制文件，它们都使用GraalJS引擎，但默认将{{js.java-package-globals}}设置为{{true}}。所以如果有人使用GraalVM的{{nodejs}}运行ClojureScript项目，他们仍然会遇到与有问题的前缀命名空间的问题。当然，这超出了ClojureScript的控制范围，但我认为这也为补丁提供了另一个视角，因为这个补丁并没有涵盖所有可能导致这个问题的路径。