Unsafe.defineAnonymousClass no longer exists in Java17!

Luc Chapon sxilderik at gmail.com
Thu Jan 25 09:45:52 UTC 2024


Thanks !

The fact is, the same war and same jvm work fine with Tomcat. And that is
puzzling us.

Message envoyé d'un téléphone portable.

Le mer. 24 janv. 2024 à 21:29, Attila Szegedi <szegedia at gmail.com> a écrit :

> Hm… Are you using the Java module system? Or is this Wildfly otherwise
> messing with class loading? If loaded through the Java module system,
> Nashorn should have no problem accessing sun.misc.Unsafe as it properly
> declares
> <https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/module-info.java#L145C5-L145C30> “require
> jdk.unsupported”. It does look like it might be somehow bundled in a WAR
> file though. Maybe that repackages it somehow?
>
> If you’re intent on “emergency” modifying your copy of Nashorn, I'd add
> another catch clause at Context.java:338
> <https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L338>
>  like
>
> catch(NoClassDefFoundError e) {
>   initFailure = new RuntimeException(e);
>   return null;
> }
>
> Although I’d be curious to know more about this error and circumstances
> under which it occurs. I’d be happy to try to debug it if you could give me
> a small reproducer. Alternatively, you could also run the java process with
> -verbose:class but it might not give us many clues.
>
> Attila.
>
> On 2024. Jan 24., at 18:55, Luc Chapon <sxilderik at gmail.com> wrote:
>
> This is my StackTrace.
> Since the line shown is the one trying to load a non existent method, I
> assumed that was the problem.
> The Exception seems to be NoClassDefFoundError instead…
>
> The environement is Wildfly 30 / jdk 17
>
> 18:31:00,119 ERROR [io.undertow.request] (default task-2) UT005023:
> Exception handling request to /HNS/HNSAdmin/query.pilot:
> java.lang.NoClassDefFoundError: sun/misc/Unsafe
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context$AnonymousContextCodeInstaller.lambda$getDefineAnonymousClass$0(
> Context.java:330)
> at java.base/java.security.AccessController.doPrivileged(
> AccessController.java:318)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context$AnonymousContextCodeInstaller.getDefineAnonymousClass(
> Context.java:328)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context$AnonymousContextCodeInstaller.<clinit>(
> Context.java:317)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context.lambda$compile$9(
> Context.java:1506)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.ScriptEnvironment.useAnonymousClasses(
> ScriptEnvironment.java:491)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context.compile(
> Context.java:1506)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context.compileScript(
> Context.java:1451)
> at
> deployment.HNS.war//org.openjdk.nashorn.internal.runtime.Context.compileScript(
> Context.java:761)
> at
> deployment.HNS.war//org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(
> NashornScriptEngine.java:528)
> at
> deployment.HNS.war//org.openjdk.nashorn.api.scripting.NashornScriptEngine.compileImpl(
> NashornScriptEngine.java:517)
> at
> deployment.HNS.war//org.openjdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(
> NashornScriptEngine.java:395)
> at
> deployment.HNS.war//org.openjdk.nashorn.api.scripting.NashornScriptEngine.eval(
> NashornScriptEngine.java:151)
> at java.scripting/javax.script.AbstractScriptEngine.eval(
> AbstractScriptEngine.java:262)
>
>
> Le mer. 24 janv. 2024 à 18:20, Attila Szegedi <szegedia at gmail.com> a
> écrit :
>
>> Hi!
>>
>> Are you experiencing this with Nashorn 15.4 from
>> https://github.com/openjdk/nashorn? This issue is supposed to have been
>> fixed since Nashorn 15.3 in this change
>> https://github.com/openjdk/nashorn/pull/16 according to the changelog:
>> https://github.com/openjdk/nashorn/blob/main/CHANGELOG.md
>>
>> You say it fails, but it’s encased in a try-catch specifically for this
>> reason. Can you give me a stack trace of how it fails?
>>
>> Attila.
>>
>>
>> On 2024. Jan 24., at 13:02, Luc Chapon <sxilderik at gmail.com> wrote:
>>
>> Hello all
>>
>> First message here
>>
>> We are facing a problem re Nashorn (latest) and java17
>>
>> In Context.java, line 330, you try to get a handle to a no longer
>> existent method, Unsafe.defineAnonymousClass
>>
>> And fail of course.
>>
>> I’m trying to rewrite this part for our own temporary urgent need
>> according to this.
>>
>> https://www.oracle.com/java/technologies/javase/17-relnote-issues.html
>>
>> core-libs
>> *➜
>> <https://www.oracle.com/java/technologies/javase/17-relnote-issues.html#JDK-8243287> Removal
>> of sun.misc.Unsafe::defineAnonymousClass*
>>
>> sun.misc.Unsafe::defineAnonymousClass API has been removed in JDK 17.
>> The API replacement is
>> java.lang.invoke.MethodHandles.Lookup::defineHiddenClass and
>> java.lang.invoke.MethodHandles.Lookup::defineHiddenClassWithClassData.
>>
>>
>> Are you aware of the problem? Is there a fix already available?
>>
>> Thank you!
>>
>> Luc Chapon
>> ChapsVision
>> Suresnes, France
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nashorn-dev/attachments/20240125/0a3478a9/attachment.htm>


More information about the nashorn-dev mailing list