Wait, wasn't "es4x" the name of the scrapped edition of ecmascript which was decided to be too ambitious and replaced by the much more conservative ES5?

Answer: no. That one was branded "e4x"

That was my first thought as well. I liked using E4X back in the day.

This is awesome.

I suppose this also means that JavaScript can use multithreading since the JVM can do this. I would love to write multithreaded JavaScript.

Sadly no. JS is not a thread safe language by design. However, JS can be used in multiple isolated threads simultaneously, and when they call into Java (or Kotlin or Scala etc) that codepath is shared, so you can use Java objects to share data between JavaScript contexts.

This is really cool, I like that a lot of great libraries are building JS SDKs. I wish they chose to use TS for this to get static typing.

From the site:

For this reason ES4X has a few packages published on npm that make the development easier by providing a small shim to map the Java API to JavaScript plus the full API as TypeScript .d.ts definition files.

It’s unclear what the trade offs are. Much improved IO, but what’s the cost? I can’t imagine there’s a free lunch.

I think NPM compatibility would not be a 100% since this runs on JVM and not node.js.

GraalJS can run Node applications. Not sure how it does though: emulating the API or interpreting Node's C/C++ with Sulong

The Node that comes with GraalVM is the real Node, but with a shim that maps the V8 API to GraalJS. And GraalJS is a very conformant implementation so compatibility is actually really good.

is this new? for a long time this was not the case

But this will need Oracle's Graal rather than the one contributed to OpenJDK? Because of the JS runtime?

No, it shouldn't, from my quick glance.

Here's a quick summary to help make things clear as mud. Graal is basically a compiler (very very incomplete summary but fine). Oracle is contributing it to OpenJDK as the JDK compiler. Truffle is a normal Java library and API for implementing programming languages in Java (again very high level incomplete summary) and it uses Graal to generate code. So you write your language in Java using Truffle as an API to do that, but get native code generated for it. They were developed together. And actually, you can actually use Truffle as a library without Graal in the mix, since it's "only" a Java library; it runs on a compatible JVM -- this is very useful for example, because the JDK running behind IntelliJ for code completion may not have Graal, but is just a normal JVM otherwise, and you really want code completion, test bench runners, etc, that require running your code under a normal JVM. But if Graal is there, it gets interesting, because fast code gets generated. This is again an incredibly incomplete summary but sufficient.

It's important to understand that Truffle is the library for programming language authors, and the "source" of the polyglot capabilities -- while Graal is the code generator.

The languages that the Graal team have implemented, such as JavaScript, are just clients of the Truffle library. Most Graal languages are just clients of Truffle and don't depend on the underlying JDK build or anything. If two languages are clients of the Truffle library, loaded into the same JVM, and properly implement the Polyglot API protocols, then they can also communicate, too.

You can just have a dependency on the Truffle JavaScript implementation, like any normal Java dependency, and it will run on the Enterprise or normal open source JVM.

The only reason you would force a dependency on the Enterprise Edition of Graal is if you relied in some specific Enterprise feature of theirs at the code level, but I don't know of any off hand; they're probably there, though. I believe you can detect this at runtime anyway and just do feature detection, too.

There are more technical details, but that's the summary. It's unclear how this will all shake out once Graal is part of OpenJDK and developed there; I suspect the Polyglot languages developed by the teams at Oracle will be moved around, but the above description should (basically) still be accurate.

Thanks for the clarification, appreciate it.

It seems that openjdk is fine: https://reactiverse.io/es4x/get-started/install.html#graalvm...

I think the OpenJDK variant has had JS for a long time now, yeah.

How can that be? I thought they only contributed the GraalVM Community Edition Java code to OpenJDK less than a month ago[0].

Also, quoting from the same announcement:

> What parts of GraalVM Community Edition does Oracle plan to contribute to the OpenJDK Community? > Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript.

I remembered the "Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript" part of the original article, hence I asked the question.

Edit: Did a bit more reading, and the main page for JS support on graalvm.org[1] has benchmarks comparing JS performance between V8, Graal CE and Graal EE. I assume that's what you were alluding to, and also answers my question (which I phrased in a bit of an xyproblem way).

[0]: https://www.graalvm.org/2022/openjdk-announcement/

[1]: https://www.graalvm.org/javascript/

Yeah sorry, I got confused. You have to have the GraalVM installed, yeah. The open source CE will do.

Both are Oracle's, what was contributed is the community edition.

And they still do like 90% of the OpenJDK work anyway.

this is very cool. i think i'd like to contribute. is the author in the thread? how can i get in contact?