Update GraalJS to 23.0.3 #7248

matthiasblaesing · 2024-04-05T19:45:18Z

Closes: #7245

pepness · 2024-04-05T22:27:24Z

Commit validation fails. All project.properties files will need to bump to at least Java 17.

javac.source=17
javac.target=17

.github/workflows/main.yml

Closes: apache#7245

The GraalVM tests have tested outdated GraalVM execution modes. In the beginning GraalVM had the mode where the base VM was installed and additional languages were installed in to that distribution. That mode was replaced by either distinctive distributions for the supported languages or by loading the JARs into the classpath. The latter approach is in line with the NetBeans approach to loading JS support through GraalVM/Truffle.

matthiasblaesing · 2024-04-07T18:44:37Z

23.0.3 is still broken arg

java.lang.NoSuchMethodError: 'void sun.misc.Unsafe.ensureClassInitialized(java.lang.Class)'
	at com.oracle.truffle.api.library.LibraryFactory.ensureLibraryInitialized(LibraryFactory.java:384)
	at com.oracle.truffle.api.library.LibraryFactory.getUncached(LibraryFactory.java:364)
	at com.oracle.truffle.api.library.LibraryFactory.<init>(LibraryFactory.java:210)
	at com.oracle.truffle.api.interop.InteropLibraryGen.<init>(InteropLibraryGen.java:178)
	at com.oracle.truffle.api.interop.InteropLibraryGen.<clinit>(InteropLibraryGen.java:169)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:529)
	at java.base/java.lang.Class.forName(Class.java:508)
	at com.oracle.truffle.api.library.LibraryFactory.loadGeneratedClass(LibraryFactory.java:791)
	at com.oracle.truffle.api.library.LibraryFactory.resolveImpl(LibraryFactory.java:740)
	at com.oracle.truffle.api.library.LibraryFactory.resolve(LibraryFactory.java:733)
	at com.oracle.truffle.api.interop.InteropLibrary.<clinit>(InteropLibrary.java:2941)

What a clusterf****. Its so great, that rhino was replaced with something "better"......

pepness

LGTM

mbien · 2024-04-08T19:43:35Z

@entlicher what is the graal-sdk JDK compatibility matrix? Version 24.0.0 sounds like it is using the old, non-jdk versioning scheme?
#7248 (comment)

lahodaj

Upgrading the GraalJS library seems like a reasonable direction to me (and when I checked, it seems to resolve the problem on JDK 22). I didn't notice the 24.0.0 release already happened, sorry. There are some tests failing, which may require a bit of investigation. Also, a few mostly small/nit comments inline.

lahodaj · 2024-04-09T06:31:36Z

ide/libs.graalsdk/external/binaries-list

@@ -14,5 +14,14 @@
 # KIND, either express or implied. See the License for the
 # specific language governing permissions and limitations
 # under the License.
-8E62643FD621053E00EE52D797C7FBD08D7FDEDC org.graalvm.sdk:graal-sdk:20.3.0
-8968BDBE4058F4E6610AF0DC184BD885B236A2B1 org.graalvm.sdk:launcher-common:20.3.0
+8AA4ECE060629AAAED57215A5FD8C377EFF1A191 org.graalvm.sdk:graal-sdk:24.0.0


Technically, graal-sdk may not be needed - it seems to be just a placeholder package, and the original packages probably have been split up into some of the other bundles here.

As a side note, maybe there's a better name for the module? maybe libs.graal?

I would prefer not to rename modules, unless necessary. We can have module_auto_deps entry, I'd stick with the current name.

lahodaj · 2024-04-09T06:34:21Z

ide/libs.graalsdk/external/binaries-list

-8968BDBE4058F4E6610AF0DC184BD885B236A2B1 org.graalvm.sdk:launcher-common:20.3.0
+8AA4ECE060629AAAED57215A5FD8C377EFF1A191 org.graalvm.sdk:graal-sdk:24.0.0
+06055903437576484DCC6545AF995FF67E0A3B55 org.graalvm.sdk:launcher-common:24.0.0
+335646EC205A3BCE0D518748D08A5C45900A9869 org.graalvm.shadowed:jline:24.0.0


I guess the license file for JLine is not present (which may be reason why the paperwork job failed). (And I don't think pure UPL would be the correct license for that.)

Fixed in #7253

lahodaj · 2024-04-09T06:35:06Z

webcommon/libs.graaljs/external/js-23.0.3-license.txt

@@ -2,8 +2,8 @@ Name: Graal SDK and Truffle API
 Description: Graal SDK and Truffle API


Nit: please rename the file to ...-24.0.0-....

Fixed in #7253

sdedic · 2024-04-09T12:37:38Z

@matthiasblaesing I'd like to participate on fixing the tests -- can I push changes to your branch, or would you prefer a separate branch over your PR ?

matthiasblaesing · 2024-04-09T16:23:41Z

@sdedic thanks for taking a look! Feel free to fork. I'd also like to continue experimenting and so it would be good if you could create a separate PR.
I'm still pondering whether it would be better to create one big "graalvm" module (this PR), that exposes its API or to keep the existing modules.

What I'm not happy with in my current approach is:

The installer that basicly disables truffle compilation:

netbeans/ide/libs.graalsdk/src/org/netbeans/libs/graalsdk/impl/Installer.java

Lines 14 to 15 in 2824013

System.setProperty( "polyglot.engine.WarnInterpreterOnly", "false" ); //NOI18N

System.setProperty( "truffle.UseFallbackRuntime", "true" ); //NOI18N
The removal of the .system graal module. Here I don't know whether or not this is a problem for GraalVM images (speed/usability)
The problems already mentioned by @lahodaj

For one problem I saw the last few days, I think I found a solution yesterday: The services of the modules need to be exported, so that they can be found by the ServiceLoader of the NetBeans module system.

mbien · 2024-04-09T20:51:50Z

I'm still pondering whether it would be better to create one big "graalvm" module (this PR),

I think a big wrapper module makes sense here and would make maintenance easier I think. Updates would update the whole dependency list of the wrapper, instead of having to track them down individually. Splitting it up would be still possible later if needed.

sdedic · 2024-04-10T13:44:49Z

I am also slightly concerned with removal of the GraalVM testsuites. The recent GraalVM for JDK21 has dropped builtin JS support, so that's fine. But GraalVM for JDK17 still has js as an installable component and according to the roadmap, JDK17 as LTS is to be supported until 9/2026 ...
If possible I'd prefer that test suite to be brought back, so it can ensure that NetBeans can smoothly run on GraalVM that includes JS support "in bootclasspath".

sdedic · 2024-04-10T14:17:36Z

@matthiasblaesing I probably do not have enough context, sorry .... what issue was addressed by setting

 System.setProperty( "polyglot.engine.WarnInterpreterOnly", "false" ); //NOI18N 
 System.setProperty( "truffle.UseFallbackRuntime", "true" ); //NOI18N

?

mbien · 2024-04-10T15:05:29Z

The recent GraalVM for JDK21 has dropped builtin JS support, so that's fine.

I am pretty sure the Graal JDK dropped everything. Languages are now regular dependencies for the application and not part of the env.

But GraalVM for JDK17 still has js as an installable component and according to the roadmap, JDK17 as LTS is to be supported until 9/2026 ...

21, 22 does not. To plan ahead we should have test setups which work on future proof deployments. The graal debugger/polyglot tests do also use far more languages than just js. The same tests use ruby, python java and js. The last bump to EOL GraalVM 11 bumped as far as possible, I literally had all releases between 11 and 21 downloaded and checked what languages they supported - since it changed from update release to update release(!) (#6369 (comment), #6369 (comment)).

neilcsmith-net · 2024-04-10T15:16:11Z

Our current roadmap has JDK 17 supported until 3/2026, and I'm not entirely sure where any decision on running on GraalVM fits into that either.

@mbien am I right in thinking that running the scripting tests on JDK 22 would have picked up the reported issue earlier?

sdedic · 2024-04-10T17:33:20Z

FYI - tests enabled in this PR are green in #7253, ready to merge into this one, after review.

.github/workflows/main.yml

matthiasblaesing · 2024-04-10T19:42:10Z

@matthiasblaesing I probably do not have enough context, sorry .... what issue was addressed by setting
 System.setProperty( "polyglot.engine.WarnInterpreterOnly", "false" ); //NOI18N 

Truffle has excessive logging, when it is run on a JVM it does not support (without JVMCI enabled). As we are aware of that fact ant that it will take years for a JVMCI supported JVM to reach all users, it is useless to show users errors, they can do nothing about.

 System.setProperty( "truffle.UseFallbackRuntime", "true" ); //NOI18N

Without it I'm seeing this:

java.lang.UnsatisfiedLinkError: Native Library /home/matthias/.cache/org.graalvm.polyglot/engine/libtruffleattach/ad91dae1c5adc8f7ce79f78620596dbbdf2c86b43891cd5aff1d62d28f41429a/bin/libtruffleattach.so already loaded in another classloader
java.lang.InternalError
	at com.oracle.truffle.runtime.ModulesSupport.loadModulesSupportLibrary(ModulesSupport.java:171)
	at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.createRuntime(HotSpotTruffleRuntimeAccess.java:84)
	at com.oracle.truffle.runtime.hotspot.HotSpotTruffleRuntimeAccess.getRuntime(HotSpotTruffleRuntimeAccess.java:75)
	at com.oracle.truffle.api.Truffle.createRuntime(Truffle.java:145)
	at com.oracle.truffle.api.Truffle$1.run(Truffle.java:176)
	at com.oracle.truffle.api.Truffle$1.run(Truffle.java:174)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at com.oracle.truffle.api.Truffle.initRuntime(Truffle.java:174)
	at com.oracle.truffle.api.impl.Accessor.getTVMCI(Accessor.java:1481)
	at com.oracle.truffle.api.impl.Accessor.engineSupport(Accessor.java:1410)
	at com.oracle.truffle.api.library.LibraryAccessor.engineAccessor(LibraryAccessor.java:57)
	at com.oracle.truffle.api.library.LibraryFactory.loadExternalDefaultProviders(LibraryFactory.java:441)
	at com.oracle.truffle.api.library.LibraryFactory.getExternalDefaultProviders(LibraryFactory.java:432)
	at com.oracle.truffle.api.library.LibraryFactory.initDefaultExports(LibraryFactory.java:220)
	at com.oracle.truffle.api.library.LibraryFactory.<init>(LibraryFactory.java:215)
	at com.oracle.truffle.api.library.DynamicDispatchLibraryGen.<init>(DynamicDispatchLibraryGen.java:34)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:534)
	at java.base/java.lang.Class.forName(Class.java:513)
	at com.oracle.truffle.api.library.LibraryFactory.loadGeneratedClass(LibraryFactory.java:777)
	at com.oracle.truffle.api.library.LibraryFactory.resolveImpl(LibraryFactory.java:758)
	at com.oracle.truffle.api.library.LibraryFactory.resolve(LibraryFactory.java:751)
	at com.oracle.truffle.api.library.LibraryFactory.<init>(LibraryFactory.java:209)
	at com.oracle.truffle.api.interop.InteropLibraryGen.<init>(InteropLibraryGen.java:181)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:534)
	at java.base/java.lang.Class.forName(Class.java:513)
	at com.oracle.truffle.api.library.LibraryFactory.loadGeneratedClass(LibraryFactory.java:777)
	at com.oracle.truffle.api.library.LibraryFactory.resolveImpl(LibraryFactory.java:758)
	at com.oracle.truffle.api.library.LibraryFactory.resolve(LibraryFactory.java:751)
	at com.oracle.truffle.polyglot.PolyglotImpl.initialize(PolyglotImpl.java:200)
	at org.graalvm.polyglot.Engine.loadAndValidateProviders(Engine.java:1706)
	at org.graalvm.polyglot.Engine$1.run(Engine.java:1732)
	at org.graalvm.polyglot.Engine$1.run(Engine.java:1727)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at org.graalvm.polyglot.Engine.initEngineImpl(Engine.java:1727)
	at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
	at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
	at org.graalvm.polyglot.Context$Builder.build(Context.java:1925)
	at org.netbeans.libs.graaljs.GraalJSTest.testDirectEvaluationOfGraalJS(GraalJSTest.java:55)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:79)
	at org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:484)
	at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:405)
	at java.base/java.lang.Thread.run(Thread.java:1583)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:167)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:139)
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2418)
	at java.base/java.lang.Runtime.load0(Runtime.java:852)
	at java.base/java.lang.System.load(System.java:2025)
	at com.oracle.truffle.runtime.ModulesSupport.loadModulesSupportLibrary(ModulesSupport.java:168)

matthiasblaesing · 2024-04-10T20:26:32Z

I pushed an update, but I'm still not happy. With that I think this works on OpenJDK 17, 21, 22 GraalVM 21, 22 and 17 (if JS is installed).

I tested the modules:

Scripting API
JavaScript on JVM
GraalVM SDK
GraalVM.js
core.network

on the mentioned JDKs. I trust the core.network tests, I don't trust the rest of them, especially not on GraalVM 17.

On GraalVM 17:

the number of GraalVM SDKs tests drops from ~1050 to 295 (I assume, some dynamic method creates test cases based on languages), what is worse I had a break point after a test assert, the break point was not hit (the assert failed), but I got not test error reported.....
the GraalVM.js tests work only when invoked manually els this is reported:

java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchMethodError: 'java.lang.String org.graalvm.polyglot.impl.AbstractPolyglotImpl.getTruffleVersion()' [in thread "Test Watch Dog: testDirectEvaluationOfGraalJS"]
  at org.graalvm.polyglot.Engine.loadAndValidateProviders(Engine.java:1665)
  at org.graalvm.polyglot.Engine$1.run(Engine.java:1732)
  at org.graalvm.polyglot.Engine$1.run(Engine.java:1727)
  at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
  at org.graalvm.polyglot.Engine.initEngineImpl(Engine.java:1727)
  at org.graalvm.polyglot.Engine$ImplHolder.<clinit>(Engine.java:190)
  at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
  at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
  at org.graalvm.polyglot.Context$Builder.build(Context.java:1925)
  at org.netbeans.libs.graaljs.GraalJSTest2$T.call(GraalJSTest2.java:137)
  at org.netbeans.libs.graaljs.GraalJSTest2.testDirectEvaluationOfGraalJS(GraalJSTest2.java:131)
Caused: java.lang.NoClassDefFoundError: Could not initialize class org.graalvm.polyglot.Engine$ImplHolder
  at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
  at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
[catch] at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.lambda$enumerateLanguages$1(GraalEnginesProvider.java:159)
  at org.netbeans.libs.graalsdk.impl.GraalContext.executeWithClassLoader(GraalContext.java:117)
  at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.enumerateLanguages(GraalEnginesProvider.java:157)
  at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.factories(GraalEnginesProvider.java:66)
  at org.netbeans.api.scripting.Scripting$EngineManager.populateExtras(Scripting.java:148)
  at org.netbeans.api.scripting.Scripting$EngineManager.<init>(Scripting.java:133)
  at org.netbeans.api.scripting.Scripting.build(Scripting.java:120)
  at org.netbeans.api.scripting.Scripting.createManager(Scripting.java:65)
  at org.netbeans.libs.graaljs.GraalJSTest2.testJavaScriptEngineIsGraalJS(GraalJSTest2.java:145)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:568)
  at junit.framework.TestCase.runTest(TestCase.java:177)
  at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:79)
  at org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:484)
  at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:405)
  at java.base/java.lang.Thread.run(Thread.java:842)
INFO [org.netbeans.libs.graalsdk.impl.GraalEnginesProvider]: Failed to initialize GraalEngines
java.lang.ExceptionInInitializerError: Exception java.lang.NoSuchMethodError: 'java.lang.String org.graalvm.polyglot.impl.AbstractPolyglotImpl.getTruffleVersion()' [in thread "Test Watch Dog: testDirectEvaluationOfGraalJS"]
  at org.graalvm.polyglot.Engine.loadAndValidateProviders(Engine.java:1665)
  at org.graalvm.polyglot.Engine$1.run(Engine.java:1732)
  at org.graalvm.polyglot.Engine$1.run(Engine.java:1727)
  at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
  at org.graalvm.polyglot.Engine.initEngineImpl(Engine.java:1727)
  at org.graalvm.polyglot.Engine$ImplHolder.<clinit>(Engine.java:190)
  at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
  at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
  at org.graalvm.polyglot.Context$Builder.build(Context.java:1925)
  at org.netbeans.libs.graaljs.GraalJSTest2$T.call(GraalJSTest2.java:137)
  at org.netbeans.libs.graaljs.GraalJSTest2.testDirectEvaluationOfGraalJS(GraalJSTest2.java:131)
Caused: java.lang.NoClassDefFoundError: Could not initialize class org.graalvm.polyglot.Engine$ImplHolder
  at org.graalvm.polyglot.Engine.getImpl(Engine.java:442)
  at org.graalvm.polyglot.Engine$Builder.build(Engine.java:740)
[catch] at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.lambda$enumerateLanguages$1(GraalEnginesProvider.java:159)
  at org.netbeans.libs.graalsdk.impl.GraalContext.executeWithClassLoader(GraalContext.java:117)
  at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.enumerateLanguages(GraalEnginesProvider.java:157)
  at org.netbeans.libs.graalsdk.impl.GraalEnginesProvider.factories(GraalEnginesProvider.java:66)
  at org.netbeans.api.scripting.Scripting$EngineManager.populateExtras(Scripting.java:148)
  at org.netbeans.api.scripting.Scripting$EngineManager.<init>(Scripting.java:133)
  at org.netbeans.api.scripting.Scripting.build(Scripting.java:120)
  at org.netbeans.api.scripting.Scripting.createManager(Scripting.java:65)
  at org.netbeans.libs.graaljs.GraalJSTest2.testDeleteASymbol(GraalJSTest2.java:158)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:568)
  at junit.framework.TestCase.runTest(TestCase.java:177)
  at org.netbeans.junit.NbTestCase.access$200(NbTestCase.java:79)
  at org.netbeans.junit.NbTestCase$2.doSomething(NbTestCase.java:484)
  at org.netbeans.junit.NbTestCase$1Guard.run(NbTestCase.java:405)
  at java.base/java.lang.Thread.run(Thread.java:842)

sdedic · 2024-04-11T10:25:58Z

what does "the GraalVM.js tests work only when invoked manually" mean ? ant test from the commandline ?

sdedic · 2024-04-11T14:37:34Z

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 - 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 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 ... it is loaded from the JDK. And all weird stuff like interface mismatches, version mismatches etc happen. Note: I need some more debugging to understand how precisely ServiceLoader escaped from NB context-class-loader here.

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).

matthiasblaesing · 2024-04-11T18:33:37Z

what does "the GraalVM.js tests work only when invoked manually" mean ? ant test from the commandline ?

Sorry, bad wording. "the GraalVM.js tests work only when invoked manually" might be better phrased "the GraalVM.js tests work only when invoked individually". I mean, that when all tests of the GraalVM.js module are run I see 3 failing and 2 successful tests. The 3 failing tests work, when run isolated.

I think it is ok, to support GaalJS 17 only on an untested basis as the platform itself is unstable (GraalVM as a whole) or a niche (GraalVM 17). I also think it is fair, that people running such an experimental platform must be prepared to take the pain (in the case of GraalVM 17, install JS).

For a future perspective, this might become a problem:

netbeans/ide/libs.graalsdk/src/org/netbeans/libs/graalsdk/impl/Installer.java

Lines 27 to 41 in 14fb065

 public void validate() { 

 super.validate(); 

 // Truffle runtime is very vocal if it is run in interpreter only mode. 

 // That mode is the case in "normal" JDKs, which are the NetBeans 

 // baseline - the warnings should be silenced accordingly 

 if (!System.getProperties().contains("polyglot.engine.WarnInterpreterOnly")) { //NOI18N 

 System.setProperty("polyglot.engine.WarnInterpreterOnly", "false"); //NOI18N 

 } 

 // The default Truffle runtime uses a native library. That library fails 

 // hard when it shall be loaded by multiple classloaders. So for now 

 // use the fallback runtime 

 if (!System.getProperties().contains("truffle.UseFallbackRuntime")) { //NOI18N 

 System.setProperty( "truffle.UseFallbackRuntime", "true" ); //NOI18N 

 } 

 }

But I have some hope, that in the future Truffle/GraalVM will not stay with native libraries per platform or have a sane strategy to work then without failing hard. Seeing a Java runtime loading a native library by default and calling that the future of the JVM can't be the future.

I reached the end of what I can do. I would only squash this.

sdedic · 2024-04-12T05:39:28Z

I do not entirely think that GraalVM is an 'exerimental' technology ... but anyway, I think there are still some issues:

published module (libs.truffleapi) is dropped that declares public packages, which might break some projects. This should be done for a reason only and if, then module_auto_deps should be used to maintain binary compatibility.
drops the possibility to go along two paths: consume JDK services and provide bundled ones; this is because drop of libs.graalsdk.system from the start. Reasons not well explained. If it can be fixed, it would be fair to drop this "dichotomy" when GraalVM for JDK 17 goes EOL or NB stops supporting JDK17, whichever comes first. I'll make a parallel experiment that does not drop this ... to see if it is workable and if it is not more hacky than the current state. Conceptual issues of this approach (supporting language injection from JDK) can be discussed here.

sdedic · 2024-04-12T05:42:28Z

@matthiasblaesing

"the GraalVM.js tests work only when invoked individually

If you mean that you did "Run test" from the IDE on an individual test* method... then it's working because the module environment for the test was not properly set up in suite(), especially the participating classloaders. In this mode, it actually used JVM's infrastructure and implementation, not the bundled one.

matthiasblaesing · 2024-04-12T18:53:16Z

I do not entirely think that GraalVM is an 'exerimental' technology ...

I consider GraalVM stable once project Galahad (integration into the JDK) has happend and the first LTS JDK with that technology is out. I'm still irritated, that Nashorn was dropped before the replacement was ready.

but anyway, I think there are still some issues:

* published module (libs.truffleapi) is dropped that declares **public** packages, which might break some projects. This should be done for a reason only and if, then `module_auto_deps` should be used to maintain binary compatibility.

I ran sigtest - and the signature of the module changed in an incompatible way. So the release major version of the module would go up and thus dependencies will break anyway.

I would also assume, that it will break again in the next few years, until the technology is stable.

* drops the possibility to go along two paths: consume JDK services and provide bundled ones; this is because drop of `libs.graalsdk.system` from the start. Reasons not well explained. If it can be fixed, it would be fair to drop this "dichotomy" when GraalVM for JDK 17 goes EOL or NB stops supporting JDK17, whichever comes first.

My reasoning: I have limited time and release of NB 22 is planed in the not too distant future. To me the question was: Support OpenJDK 22 or GraalVM 17. Supporting the current JVM is IMHO more important, that a VM with experimental extensions. This was the state I could reach with my resources. I never claimed, that it was the best/right approach.

I'll make a parallel experiment that does not drop this ... to see if it is workable and if it is not more hacky than the current state. Conceptual issues of this approach (supporting language injection from JDK) can be discussed here.

I would prefer a better solution, so it would be great if you could come up with one. 😆

sdedic · 2024-04-12T18:56:52Z

@matthiasblaesing understood... I planned to work on this today, but other schedule creeped in (sorry), so I hope I'll do something over the weekend to have a stable thing (or a failure ;)) before branching.

matthiasblaesing · 2024-04-17T16:41:43Z

Abandoned in favor of #7268

mbien added the Upgrade Library Library (Dependency) Upgrade label Apr 5, 2024

matthiasblaesing force-pushed the update_truffle_js branch from d35c809 to 7c265c6 Compare April 6, 2024 14:33

mbien reviewed Apr 6, 2024

View reviewed changes

.github/workflows/main.yml Outdated Show resolved Hide resolved

matthiasblaesing force-pushed the update_truffle_js branch 2 times, most recently from da32e87 to 32a10a6 Compare April 7, 2024 11:44

matthiasblaesing added 3 commits April 7, 2024 19:06

Update GraalJS to 23.0.3

970db3e

Closes: apache#7245

Fix unittests for core.network - add graaljs as test dependency

488debb

matthiasblaesing force-pushed the update_truffle_js branch from 32a10a6 to 3ab04b1 Compare April 7, 2024 17:08

matthiasblaesing mentioned this pull request Apr 7, 2024

NetBeans bundled Truffle Version incompatbile with JDK 22 #7245

Closed

matthiasblaesing added the do not merge Don't merge this PR, it is not ready or just demonstration purposes. label Apr 7, 2024

pepness approved these changes Apr 8, 2024

View reviewed changes

Minimal working implementation of a working GraalVM/GraalJS setup

2824013

lahodaj reviewed Apr 9, 2024

View reviewed changes

matthiasblaesing added 2 commits April 9, 2024 20:06

Improve license info / remove graal-sdk artifact

8665673

Fix license 2

1b79632

sdedic mentioned this pull request Apr 10, 2024

Fix tests for GraalJS update #7253

Closed

matthiasblaesing and others added 2 commits April 10, 2024 18:25

Add missing js-launcher

c9998f6

Enable module container for proper graaljs classloading

c1b1dd5

mbien reviewed Apr 10, 2024

View reviewed changes

.github/workflows/main.yml Outdated Show resolved Hide resolved

matthiasblaesing added 3 commits April 10, 2024 21:40

Reduce system property modifications for GraalVM

5f041ab

Remove OpenIDE-Module-Hide-Classpath-Packages to support GraalVM 17

112fa4b

Restore core.networking test to its original location

d6ed8e4

matthiasblaesing force-pushed the update_truffle_js branch from 03bd981 to d6ed8e4 Compare April 10, 2024 20:18

matthiasblaesing added 4 commits April 11, 2024 17:47

Log errors when initialization of GraalEngines fails

b2d2e20

Fix license header

0b90a1a

Fix version in js license file

4c46599

Complete graalvm <= 17 removal

14fb065

Fix endless loop when determining GraalSDK dependent modules

2244019

sdedic mentioned this pull request Apr 15, 2024

Update libs.graaljs, libs.graalsdk and libs.truffleapi to 24.0.0 #7268

Merged

matthiasblaesing closed this Apr 17, 2024

matthiasblaesing deleted the update_truffle_js branch April 19, 2024 16:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update GraalJS to 23.0.3 #7248

Update GraalJS to 23.0.3 #7248

matthiasblaesing commented Apr 5, 2024

pepness commented Apr 5, 2024

matthiasblaesing commented Apr 7, 2024

pepness left a comment

mbien commented Apr 8, 2024

lahodaj left a comment

lahodaj Apr 9, 2024

sdedic Apr 10, 2024

lahodaj Apr 9, 2024

sdedic Apr 10, 2024

lahodaj Apr 9, 2024

sdedic Apr 10, 2024

sdedic commented Apr 9, 2024

matthiasblaesing commented Apr 9, 2024

mbien commented Apr 9, 2024

sdedic commented Apr 10, 2024

sdedic commented Apr 10, 2024

mbien commented Apr 10, 2024 •

edited

Loading

neilcsmith-net commented Apr 10, 2024

sdedic commented Apr 10, 2024

matthiasblaesing commented Apr 10, 2024

matthiasblaesing commented Apr 10, 2024

sdedic commented Apr 11, 2024

sdedic commented Apr 11, 2024 •

edited

Loading

matthiasblaesing commented Apr 11, 2024

sdedic commented Apr 12, 2024 •

edited

Loading

sdedic commented Apr 12, 2024

matthiasblaesing commented Apr 12, 2024

sdedic commented Apr 12, 2024 •

edited

Loading

matthiasblaesing commented Apr 17, 2024

		@@ -2,8 +2,8 @@ Name: Graal SDK and Truffle API
		Description: Graal SDK and Truffle API

Update GraalJS to 23.0.3 #7248

Update GraalJS to 23.0.3 #7248

Conversation

matthiasblaesing commented Apr 5, 2024

pepness commented Apr 5, 2024

matthiasblaesing commented Apr 7, 2024

pepness left a comment

Choose a reason for hiding this comment

mbien commented Apr 8, 2024

lahodaj left a comment

Choose a reason for hiding this comment

lahodaj Apr 9, 2024

Choose a reason for hiding this comment

sdedic Apr 10, 2024

Choose a reason for hiding this comment

lahodaj Apr 9, 2024

Choose a reason for hiding this comment

sdedic Apr 10, 2024

Choose a reason for hiding this comment

lahodaj Apr 9, 2024

Choose a reason for hiding this comment

sdedic Apr 10, 2024

Choose a reason for hiding this comment

sdedic commented Apr 9, 2024

matthiasblaesing commented Apr 9, 2024

mbien commented Apr 9, 2024

sdedic commented Apr 10, 2024

sdedic commented Apr 10, 2024

mbien commented Apr 10, 2024 • edited Loading

neilcsmith-net commented Apr 10, 2024

sdedic commented Apr 10, 2024

matthiasblaesing commented Apr 10, 2024

matthiasblaesing commented Apr 10, 2024

sdedic commented Apr 11, 2024

sdedic commented Apr 11, 2024 • edited Loading

matthiasblaesing commented Apr 11, 2024

sdedic commented Apr 12, 2024 • edited Loading

sdedic commented Apr 12, 2024

matthiasblaesing commented Apr 12, 2024

sdedic commented Apr 12, 2024 • edited Loading

matthiasblaesing commented Apr 17, 2024

mbien commented Apr 10, 2024 •

edited

Loading

sdedic commented Apr 11, 2024 •

edited

Loading

sdedic commented Apr 12, 2024 •

edited

Loading

sdedic commented Apr 12, 2024 •

edited

Loading