-
Bug
-
Resolution: Not a Bug
-
Major
-
29.0.1.Final
-
None
-
---
-
---
During an upgrade from Wildfly 27.0.1-JDK17 to Wildfly 29.0.1-JDK17 I came across a problem related to GaalVM Script Engine and the class sun.misc.Unsave.
In our open source project imixs-workflow we are using the GraalVM Script engine to support scripting languages. We depend on GaalVM 22.3.5
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js</artifactId>
<version>22.3.5</version>
</dependency>
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-scriptengine</artifactId>
<version>22.3.5</version>
</dependency>
The relevant piece of code looks like this:
_context = Context.newBuilder("js") // .option("engine.WarnInterpreterOnly", "false") // .allowAllAccess(true) // .build();
This all works fine in Wildfly 27.0.1-Final-JDK-17, but deploying the code in Wildfly 29. caused first the error:
Polyglot version compatibility check failed. The polyglot version '24.1.2' is not compatible to the used Truffle version '23.1.1'. The Truffle or language version is older than the polyglot version in use. The polygot and truffle version must always match. Update the Truffle or language versions to '24.1.2' to resolve this.
This error is ok and we upgraded to GraalVM 24.1.2
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-scriptengine</artifactId>
<version>24.1.2</version>
</dependency>
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-language</artifactId>
<version>24.1.2</version>
</dependency>
Between GraalVM 22 and 23, 24 there is some major change regarding the library packaging in the script engine. But I am not sure if this is related to the following problem:
Deploying the .war file with GraalVM Script engine 24.1.2 caused the following runtime exception when the script engine is initialized with the code above:
Caused by: java.lang.NoClassDefFoundError: sun/misc/Unsafe
my-app.war//com.oracle.truffle.api.dsl.InlineSupport$UnsafeField.getUnsafe(InlineSupport.java:1346)
my-app.war//com.oracle.truffle.api.dsl.InlineSupport$UnsafeField.<clinit>(InlineSupport.java:1358)
my-app.war//com.oracle.truffle.api.strings.TruffleStringFactory$HashCodeNodeGen.<clinit>(TruffleStringFactory.java:2013)
my-app.war//com.oracle.truffle.api.strings.TruffleString$HashCodeNode.getUncached(TruffleString.java:3113)
my-app.war//com.oracle.truffle.api.strings.TruffleString$HashCodeNode.calculateHashCodeUncached(TruffleString.java:3121)
my-app.war//com.oracle.truffle.api.strings.AbstractTruffleString.hashCode(AbstractTruffleString.java:1321)
my-app.war//com.oracle.truffle.api.strings.TruffleString.createConstant(TruffleString.java:191)
my-app.war//com.oracle.truffle.api.strings.TruffleString.createConstant(TruffleString.java:185)
my-app.war//com.oracle.truffle.api.strings.TruffleString$Encoding.<clinit>(TruffleString.java:1062)
my-app.war//com.oracle.truffle.polyglot.PolyglotValueDispatch.createDefaultValues(PolyglotValueDispatch.java:1704)
my-app.war//com.oracle.truffle.polyglot.PolyglotImpl.initialize(PolyglotImpl.java:205)
my-app.war//org.graalvm.polyglot.Engine.loadAndValidateProviders(Engine.java:1691)
my-app.war//org.graalvm.polyglot.Engine$1.run(Engine.java:1717)
my-app.war//org.graalvm.polyglot.Engine$1.run(Engine.java:1712)
The problem seems to be that the class sun.misc.Unsave is no longer loaded by the Wildfly Classloader. I think this classs is part of the JDK somehow, as a maven build with openJDK 17 has no problem with this library. And the class is somewhere used by the GraalVM Scriptengine deep inside.
My solution now was to define a custom module in wildfly:
<module name="org.graalvm" xmlns="urn:jboss:module:1.6"> <properties> <property name="jboss.api" value="public" /> </properties> <dependencies> <system export="true"> <paths> <!-- GrallVM Scriptengine support --> <path name="sun/misc" /> </paths> </system> </dependencies> </module>
and add the following deployment descriptor jboss-deployment-structure.xml into my application:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.graalvm" export="true" />
</dependencies>
</deployment>
</jboss-deployment-structure>
This solved the class loading problem and all works fine like before in Wildfly 27.0
I wonder if my approach makes sense. It is extremely cumbersome. Is there a reason why the class is no longer loaded by Wildfly, and is there a more elegant way as to activate the class via a deployment descriptor in my application? The deployment descriptor makes our entire open source project less interoperable. Therefore, I would like to find a way to get Wildfly to load the class in general.
Is this possible, or is this a known bug?
