sdedic commented on PR #7248:
URL: https://github.com/apache/netbeans/pull/7248#issuecomment-2049845681
Well. There are 3 possible cases with different versions / states of GraalVM.
Easiest: GraalVM **for JDK 21** or generally GraalVM JDKs of internal
version greater (I hope) or equal to **23.1.0** -- these *do not contain*
org.graalvm.sdk module at all, so Polyglot class API and truffle API is not
available on the bootclassspath. No `gu` is provided to install optional
components, so the user cannot change JDK state/configuration. Good. Nothing
messes/mixes with our distributed libraries, so **GraalVM for JDK21, for JDK22*
and any non-Graal JDK is OK.
Now GraalVM for JDK17, *without* JS installed. I did a bad job validating my
changes. Because this combination fails:
```
Allowed engines: GraalVM:js,Graal.js,Nashorn
Found engines:
freemarker
NetBeans indentation
Will not resolve proxy configuration.
```
The GraalVM does not contain `javascript` implementation, but **does
contain** Polyglot and Truffle classes. So provided that
[`OpenIDE-Module-Hide-Classpath-Packages` was
removed](https://github.com/apache/netbeans/pull/7248/commits/112fa4b83fe5f6e4bf0e98a6c53b77da8e8195df)
- NetBeans will load the JDK-provided infrastructure for its libs.graalsdk
`EngineProvider` impl. Those JDK classes do not care at all about that NetBeans
provide some language implementation. JDK-provided Polyglot reports "no
javascript", so there's none.
Third option, GraalVM for JDK17 (better: JDK with polyglot API) *and js
installed in it*: things are fine - Jbecause JDK-provided JS implementation is
loaded. Although that wasn't the exactly for why `libs.graalsdk` was
implemented for: there once was `libs.graalsdk.system` that aimed to load
strictly classes from the JDK, if there was any Polyglot available on bootstrap
path. But - the test works, so OK.
Why the tests for `libs.graaljs` fail ? That's because they specifically
test that that provided Javascript implementation is OK. It wasn't developet to
test "just random" javascript implementation, picked from the environment, but
the bundled one. The testsuite tries hard to load NetBeans classes, despite
(feared) JDK-provided Polyglot API classes present in tests' JVM. So it loads
the Polyglot API from the NetBeans. This is where the `Hide-Packages` and
`libs.truffleapi` removal steps in: it will nicely load NB-distributed Polyglot
API (because of special classloader is used) ... but when Polyglot itself
attempts to use SerivceLoader classes to its own Truffle implementation by name
...
... the class is not exported (it was, in `libs.truffleapi`, but the
relevant `Public-Packages` entry is not in this PR. So it is loaded from the
JDK. And all weird stuff like interface mismatches, version mismatches etc
happen.
So one way is to fix the test. It can run without the classloading wrapper
on non-polyglot GraalVM _and_ on Polyglot + JS enabled GraalVM. It will not
succeed on Polyglot JDK without JS as JS won't be enumerated by JDK. This also
means that NB will not be able to bring its JS implementation working on
Polyglot JDK without JS installed in it (= GraalVM for JDK17 and older
GraalVMs, like 22.3 /JDK17).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
