You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently explored using the GraalJS script-engine as a replacement for the few bits of JS that shadow-cljs currently uses Nashorn for. Nashorn is going away and GraalJS seems to be well supported so that seems like a viable way forward.
It is rather easy to get release builds working in the script-engine but I'd also like to get the usual watch workflow going and have hot-reload/REPL.
The main hurdle here is getting the async parts to work.
GraalJS by default has no async support so requires basic shims for even setTimeout or setInterval. CLJS had some basic shims for that but they were recently removed. I don't like the approach of the JS creating its own threads. I'm not exactly sure how GraalJS handles multi-threading and will need to investigate this further. Multi-threaded JS scares me.
The generated JS could either use the JVM WebSocket (JVM11+ only though) to communicate with shadow-cljs just like any other target does or talk directly to the running JVM shadow-cljs instance. The most common case however will likely not have shadow-cljs running in the same JVM so some kind of remote seems best. Could drop down to regular java.net.Socket if JDK 8 support was required.
I would like a non-invasive approach where the consumer just loads a .js file but makes no other adjustments between dev/release builds (apart from maybe adjusting a few permissions).
Currently I can't think of any way of doing this besides actually creating Threads in JS. Might be useful to create a shadow.graal library of so that abstracts the threading parts away in a sane way where the JVM stays in control and provides a basic event-loop.
Might also just provide a basic GraalJS REPL where shadow-cljs manages the entire Context (like node-repl) and only supports building release builds for embedding elsewhere.
The text was updated successfully, but these errors were encountered:
Note: THIS IS NOT ABOUT GraalVM.
I recently explored using the GraalJS script-engine as a replacement for the few bits of JS that shadow-cljs currently uses Nashorn for. Nashorn is going away and GraalJS seems to be well supported so that seems like a viable way forward.
It is rather easy to get
release
builds working in the script-engine but I'd also like to get the usualwatch
workflow going and have hot-reload/REPL.The main hurdle here is getting the async parts to work.
GraalJS by default has no async support so requires basic shims for even
setTimeout
orsetInterval
. CLJS had some basic shims for that but they were recently removed. I don't like the approach of the JS creating its own threads. I'm not exactly sure how GraalJS handles multi-threading and will need to investigate this further. Multi-threaded JS scares me.The generated JS could either use the JVM WebSocket (JVM11+ only though) to communicate with shadow-cljs just like any other target does or talk directly to the running JVM shadow-cljs instance. The most common case however will likely not have shadow-cljs running in the same JVM so some kind of remote seems best. Could drop down to regular
java.net.Socket
if JDK 8 support was required.I would like a non-invasive approach where the consumer just loads a
.js
file but makes no other adjustments between dev/release builds (apart from maybe adjusting a few permissions).Currently I can't think of any way of doing this besides actually creating Threads in JS. Might be useful to create a
shadow.graal
library of so that abstracts the threading parts away in a sane way where the JVM stays in control and provides a basic event-loop.Might also just provide a basic GraalJS REPL where shadow-cljs manages the entire Context (like
node-repl
) and only supports buildingrelease
builds for embedding elsewhere.The text was updated successfully, but these errors were encountered: