`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包全局变量。

我更倾向于 clojure 和 running on 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 还没有推出很长时间，这样的变更不太可能破坏任何人。如果确实这样，可以覆盖默认设置。

（链接：~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 已添加到补丁申请 (i)

Answer 10

评论由：mfikes

CLJS-3087-2.patch LGTM (y)

Answer 11

评论由：kommen

在(链接： 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)。
空值

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 的控制范围，但我认为这从另一个角度看待该补丁，因为它并没有涵盖所有可能导致此问题的可能路径。