以 `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}} 设置为禁用它是否足够解决这个问题，或者这会引入其他问题。


命令：$ 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环境中运行时的全局变量存在情况的应用程序造成破坏性变化。

Answer 5

评论者：kommen

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

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

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}}（待与Nashorn兼容）代替，这样就可以使用关闭了{{js.java-package-globals}}的GraalJS命令行工具，并且生成的主文件仍然可以工作。

Answer 8

评论者：mfikes

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

Answer 9

评论者：mfikes

CLJS-3087-2.patch 已添加到Patch Tender (i)

Answer 10

评论者：mfikes

CLJS-3087-2.patch 被认可 (y)

Answer 11

评论者：kommen

在 traitement 과제 seline (链接: 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])
执行错误 () at (<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 的控制范围，但我认为它为补丁提供了另一个视角，因为这个补丁并没有涵盖所有可能导致此问题的路径。