graaljs: Exception when run from uber-jar

I am trying to use Graal.JS as a Nashorn replacement. I basically followed the instructions here. I think the one relevant caveat is that I running this on Windows 10.

The js and js-scriptengine artifacts are brought in using Maven and the project runs fine using IntelliJ. I use Maven to create an uber-jar and when I try and run a script from this uber-jar I get the following exception:

Mar 4, 2019 @ 3:36:57 PM - EXCEPTION - org.graalvm.polyglot.PolyglotException: java.lang.IllegalStateException: No language for id regex found. Supported languages are: [js]
	at com.oracle.truffle.polyglot.PolyglotEngineImpl.findLanguage(PolyglotEngineImpl.java:446)
	at com.oracle.truffle.polyglot.PolyglotImpl$EngineImpl.parseForLanguage(PolyglotImpl.java:473)
	at com.oracle.truffle.api.TruffleLanguage$Env.parse(TruffleLanguage.java:1786)
	at com.oracle.truffle.js.runtime.JSContext.getRegexEngine(JSContext.java:958)
	at com.oracle.truffle.js.runtime.RegexCompilerInterface.compile(RegexCompilerInterface.java:75)
	at com.oracle.truffle.js.runtime.RegexCompilerInterface.compile(RegexCompilerInterface.java:66)
	at com.oracle.truffle.js.nodes.access.RegExpLiteralNode.execute(RegExpLiteralNode.java:92)
	at com.oracle.truffle.js.nodes.function.JSFunctionCallNode$InvokeNNode.executeFillObjectArray(JSFunctionCallNode.java:898)
	at com.oracle.truffle.js.nodes.function.JSFunctionCallNode$InvokeNNode.createArguments(JSFunctionCallNode.java:891)
	at com.oracle.truffle.js.nodes.function.JSFunctionCallNode$InvokeNode.execute(JSFunctionCallNode.java:754)
	at com.oracle.truffle.js.nodes.access.JSWriteCurrentFrameSlotNodeGen.execute_generic3(JSWriteCurrentFrameSlotNodeGen.java:149)
	at com.oracle.truffle.js.nodes.access.JSWriteCurrentFrameSlotNodeGen.execute(JSWriteCurrentFrameSlotNodeGen.java:84)
	at com.oracle.truffle.js.nodes.access.JSWriteCurrentFrameSlotNodeGen.executeVoid(JSWriteCurrentFrameSlotNodeGen.java:281)
	at com.oracle.truffle.js.nodes.control.AbstractBlockNode.executeVoid(AbstractBlockNode.java:74)
	at com.oracle.truffle.js.nodes.control.BlockNode.execute(BlockNode.java:62)
	at com.oracle.truffle.js.nodes.function.FunctionBodyNode.execute(FunctionBodyNode.java:66)
	at com.oracle.truffle.js.nodes.function.FunctionRootNode.executeInRealm(FunctionRootNode.java:147)
	at com.oracle.truffle.js.runtime.JavaScriptRealmBoundaryRootNode.execute(JavaScriptRealmBoundaryRootNode.java:92)

I assume the uber-jar is messing up the manifests or something but it is out of my skill range to be sure.

Any thoughts on this?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 29 (4 by maintainers)

Commits related to this issue

Most upvoted comments

I didn’t have to update shade or jar plugin at all just added the file.

src/main/resources/META-INF/truffle/language

#https://github.com/graalvm/graaljs/issues/125

language1.characterMimeType.0=application/tregex
language1.className=com.oracle.truffle.regex.RegexLanguage
language1.id=regex
language1.implementationName=
language1.interactive=false
language1.internal=true
language1.name=REGEX
language1.version=0.1

language2.characterMimeType.0=application/javascript
language2.characterMimeType.1=application/javascript+module
language2.characterMimeType.2=text/javascript
language2.className=com.oracle.truffle.js.lang.JavaScriptLanguage
language2.defaultMimeType=application/javascript
language2.dependentLanguage.0=regex
language2.fileTypeDetector0=com.oracle.truffle.js.lang.JSFileTypeDetector
language2.id=js
language2.implementationName=GraalVM JavaScript
language2.interactive=true
language2.internal=false
language2.name=JavaScript
language2.version=inherit

hth!

This is less than ideal at the moment as we are currently using this custom registration mechanism for languages at the moment. We plan to switch to a different more standard service provider approach, that uber-jar will be able to handle without further configuration. It is a bigger change though.

The issue is that the graal languages “js” and “regex” both contain a propery file with the same name and location, so when you do an uber-jar one override the other and breaks. You should either write a transformer to merge the 2 or relocate the sources.

You cannot just append the 2 because the properties are index based and both files declare the languages at index 0.

This is just sharing information but I had same issue and I resolve this issue by below. If you are building fat jar with com.github.johnrengelman.shadow, maybe it will help.

// build.gradle.kts
shadowJar {
    // adding this
    mergeServiceFiles()
}

looks like we have switched to the META-INF/services/com.truffle.api.TruffleLanguage$Provider (which is GREAT)

So just use the maven shade plugin transformer to merge the contents of those files

transformer implementation=“org.apache.maven.plugins.shade.resource.ServicesResourceTransformer”

will produce.

com.oracle.truffle.js.lang.JavaScriptLanguageProvider com.oracle.truffle.regex.RegexLanguageProvider

happy graal’n

Hi, guys still facing this issue for the latest version. Any help would be appreciated!

If you are using a shaded jar with maven-shade you can try adding a ServiceTransformer: https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ServicesResourceTransformer

This solved it for me as otherwise the services overwrote eachother, i.e. pretty much the original issue here, just a different flavor.

Hi, guys still facing this issue for the latest version. Any help would be appreciated!

In the end, for the time being, referencing the libraries using the classpath and not using a fat-jar/uber-jar was the solution for this issue (as mentioned above). It may not be “ideal” but it works, and (at least in my case) I needed it to work. Have a great day!

Another thing I remember from this when I’ve discussed it a while ago… uber-jars will give you even more trouble once you run your code on JDK11, because if the upstream jars include “module-info.class” files they will most likely shade each other breaking the exports/imports of the java module system.

I’ve discussed this issue with @chumer back in December and in order to embrace the future, the best is to have either your jars on the classpath/modulepath as this will even allow you to do jlink images.

For reference here is where this issue was reported to es4x: https://github.com/reactiverse/es4x/issues/57