以 `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}}也能解决这个问题，因为提供了更多的“tlds”（Packages, java, javafx, javax, com, org, edu）这将修复它们的用法。正如Mike指出，这将会造成一个破坏性的变化，因为在graal env下运行时，有人可能会依赖于这些全局变量。

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的{{js}}命令行工具，同时产物的主要文件仍然可以工作。

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

在 graaljs 问题的页面（链接：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])
执行错误 () 在 (<cljs repl>:1)。
null

Answer 13

评论者：dnolen

迪特尔，我不明白你关于 js 和 nodejs 的最后一个评论。它们受到了什么影响？

Answer 14

评论者：dnolen

我倾向于第二个补丁，该补丁禁用了隐式全局导入。无论如何这都不是一件好事 ... 对于另一个工单 - 但是在 wonder 如果我们应该有对 Java 包的 require 支持。

Answer 15

评论者：kommen

(链接: ~dnolen) GraalVM 附带了 {{bin/js}} 和 {{bin/nodejs}} 可执行文件，它们都使用 GraalJS 引擎，但默认 {{js.java-package-globals}} 为 {{true}}。因此，如果使用 GraalVM 的 {{nodejs}} 运行 ClojureScript 实体，则仍会遇到以有问题的前缀之一的命名空间问题。这当然超出了 ClojureScript 的控制范围，但我认为这从另一个角度审视补丁，因为它并没有覆盖所有可能引发此问题的路径。