以`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)
执行错误（错误）在（: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包全局变量作为快捷方式。该功能仍然可以通过{{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}}，以便在启用{{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

在 (链接: 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) 出现执行错误 ()
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无权控制这一点，但我认为这使补丁的视角更加深入，因为它并未涵盖所有可能导致该问题的路径。