以 `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}}同样可以解决问题，由于提供了更多的“顶级域名”（包、java、javafx、javax、com、org、edu），这将解决这些的全局变量使用问题。正如Mike所指出的，这将是一个破坏性变更，如果有人依赖于在graal环境下运行时这些全局变量的存在。

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}}（等待与Nashorn兼容），这样就可以使用关闭{{js.java-package-globals}}的GraalJS {{js}}命令行工具，同时仍使生产的主要文件工作。

Answer 8

评论由：mfikes 提出

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

Answer 9

评论由：mfikes 提出

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

Answer 10

评论由：mfikes 提出

CLJS-3087-2.patch LGTM (y)

Answer 11

评论由：kommen 提出

在graaljs问题（链接：[https://github.com/graalvm/graaljs/issues/164](https://github.com/graalvm/graaljs/issues/164) 文本：graaljs issue）的说明中，他们不打算更改{{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

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