以 `com` 开头的命名空间在 graaljs replenv 中损坏

Question

已安装 graal


$ java -version
openjdk 版本 "1.8.0_212"
OpenJDK 运行时环境 (build 1.8.0_212-20190420112649.buildslave.jdk8u-src-tar--b03)
OpenJDK GraalVM CE 19.0.0 (build 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"（软件包、java、javafx、javax、com、org、edu），这也会修复这些命名空间的使用。正如Mike指出的，这将会是一个破坏性的更改，因为如果有人在Graal环境中运行时依赖于这些全局变量，那么将会出现问题。

Answer 5

评论者：kommen

CLJS-3087-2.patch默认关闭了java包全局变量。

我更倾向于Clojure和ClojureScript在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兼容），这样一个人可以在关闭 {{js.java-package-globals}} 的情况下使用GraalJS的 {{js}} 命令行工具，同时确保生成的主文件仍然可以使用。

Answer 8

评论者：mfikes

CLJS-3087-2.patch通过CI测试（/）

Answer 9

评论者：mfikes

将 CLJS-3087-2.patch 添加到 Patch Tender (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 发布的评论

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 的控制范围，但我认为这为补丁提供了另一个视角，因为该补丁并未涵盖可能导致此问题的所有可能路径。