以 `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包 globale。

我更倾向于与其他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兼容），这样就可以在使用GraalJS的{{js}}命令行工具同时关闭{{js.java-package-globals}}并仍然使生成的主文件工作。

Answer 8

评论者：mfikes

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

Answer 9

评论者：mfikes

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

Answer 10

评论者：mfikes

CLJS-3087-2.patch 获得批准 (y)

Answer 11

评论者：kommen

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

Answer 12

由：kommen_ 发表评论

一个现实世界的示例 encounter 此问题



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 发表评论

Dieter，我不明白您关于 js 和 nodejs 的最后一条评论。它们是如何受到影响？

Answer 14

由：dnolen 发表评论

我倾向于第二个修理方案，该方案禁用了隐式的全局导入。在任何情况下这都是一件很恶心的事情 ... 对于另一个票据 - 但 wondered，我们是否应该为 Java 包提供 require 支持。

Answer 15

评论者：kommen

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