Yes, you can!
GraalJS is available on Maven Central, so nothing stops you from using it:
As always, you need to check the license. You're lucky. GraalJS is distributed under a Universal Permissive License, Version 1.0. The
pom.xml even lists the MIT license, but I didn't find any reference to the MIT license outside the
pom.xml, so I'm not sure about that.
Unfortunately, GraalJS has been written with the GraalVM compiler in mind, so you end up with a severe performance penalty. That's not always a big deal, but you'll want to add the GraalVM JIT compiler if it is. That, in turn, forces you to start the JVM with additional command-line parameters. Otherwise, the extra compiler isn't recognized. So it's only an option for those already in the DevOps world. At least, I haven't met an operations department yet that allows me to add switches like
Read the official GraalVM documentation for a walk-through. Florian Enner's "World beyond Nashorn" is also an interesting read.
Wrapping it up
My recommendation is to migrate to GraalVM. It's a plug-in replacement to your JDK, so I don't expect any problems (but, of course, you never know). You only have to check your license requirements: GraalVM ships under a GPL V2 license with the classpath exception. The Java world has lived with this license for ages, so that won't cause trouble. Still, it's worth noting because most OpenJDKs ship with different, usually more permissive, licenses.
However, if embracing GraalVM isn't an option, there's nothing wrong with using GraalJS on a stock JDK. The two links above guide you through the way.
- Native images start faster and deliver better performance during the cold start. However, unless you're using the profile-guided optimization of the Enterprise Edition, the peak performance doesn't match the peak performance of the JIT compiler.↩