I stopped looking for the cause of the NoClassDefFoundError, and trapped it as you advised.
I generated a local 15.4.1 on our artifactory, and it works – as intended. Not commiting anything on your github of course. Thank you very much! Le jeu. 25 janv. 2024 à 10:45, Luc Chapon <[email protected]> a écrit : > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> >>> >>
