Problems loading jcef.dll with AdoptOpenJDK

Having problems with building or using the JCEF Java binding? Ask your questions here.

Problems loading jcef.dll with AdoptOpenJDK

Postby KorewaLi » Tue Aug 31, 2021 4:09 am

OS: Window 10 LTSC

Project: https://github.com/Ruinscraft/mcef/
JCEF source: https://mcef.azusahideout.ml/1.31/jcef

Issue happens with </jdk-8.0.292.10-hotspot> and </jdk-8.0.292.10-openj9>
Can't produce when using Oracle Java <jre1.8.0_181>

Code: Select all
net.minecraftforge.fml.common.LoaderExceptionModCrash: Caught exception from Minecraft Chromium Embedded Framework (mcef)
Caused by: java.lang.UnsatisfiedLinkError: D:\Game\MultiMC\instances\1.12.2\.minecraft\jcef\jcef.dll: Can't find dependent libraries
   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1934)
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1817)
   at java.lang.Runtime.load0(Runtime.java:810)
   at java.lang.System.load(System.java:1088)
   at org.cef.CefApp.startup(CefApp.java:484)
   at net.montoyo.mcef.client.ClientProxy.onInit(ClientProxy.java:143)
   at net.montoyo.mcef.MCEF.onInit(MCEF.java:62)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at net.minecraftforge.fml.common.FMLModContainer.handleModStateEvent(FMLModContainer.java:637)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Subscriber.java:91)
   at com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod(Subscriber.java:150)
   at com.google.common.eventbus.Subscriber$1.run(Subscriber.java:76)
   at com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:399)
   at com.google.common.eventbus.Subscriber.dispatchEvent(Subscriber.java:71)
   at com.google.common.eventbus.Dispatcher$PerThreadQueuedDispatcher.dispatch(Dispatcher.java:116)
   at com.google.common.eventbus.EventBus.post(EventBus.java:217)
   at net.minecraftforge.fml.common.LoadController.sendEventToModContainer(LoadController.java:219)
   at net.minecraftforge.fml.common.LoadController.propogateStateMessage(LoadController.java:197)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Subscriber.java:91)
   at com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod(Subscriber.java:150)
   at com.google.common.eventbus.Subscriber$1.run(Subscriber.java:76)
   at com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:399)
   at com.google.common.eventbus.Subscriber.dispatchEvent(Subscriber.java:71)
   at com.google.common.eventbus.Dispatcher$PerThreadQueuedDispatcher.dispatch(Dispatcher.java:116)
   at com.google.common.eventbus.EventBus.post(EventBus.java:217)
   at net.minecraftforge.fml.common.LoadController.distributeStateMessage(LoadController.java:136)
   at net.minecraftforge.fml.common.Loader.initializeMods(Loader.java:749)
   at net.minecraftforge.fml.client.FMLClientHandler.finishMinecraftLoading(FMLClientHandler.java:336)
   at net.minecraft.client.Minecraft.func_71384_a(Minecraft.java:535)
   at net.minecraft.client.Minecraft.func_99999_d(Minecraft.java:378)
   at net.minecraft.client.main.Main.main(SourceFile:123)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at net.minecraft.launchwrapper.Launch.launch(Launch.java:135)
   at net.minecraft.launchwrapper.Launch.main(Launch.java:28)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:498)
   at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:210)
   at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:245)
   at org.multimc.EntryPoint.listen(EntryPoint.java:143)
   at org.multimc.EntryPoint.main(EntryPoint.java:34)
KorewaLi
Newbie
 
Posts: 1
Joined: Tue Aug 31, 2021 4:03 am

Re: Problems loading jcef.dll with AdoptOpenJDK

Postby magreenblatt » Tue Aug 31, 2021 8:18 am

AdaptOpenJDK is not supported. That said, you may be able to fix the issue by adding more folders to your PATH (e.g. all folders containing CEF and JDK dlls).
magreenblatt
Site Admin
 
Posts: 12379
Joined: Fri May 29, 2009 6:57 pm

Re: Problems loading jcef.dll with AdoptOpenJDK

Postby Phylanx » Wed Sep 01, 2021 1:10 am

Oh, didn't know, AdoptOpenJDK is not supported.
We use our JCEF Integration (version 4147) with AdoptOpenJDK.

AdoptOpenJDK Versions that worked for us:
- 1.8.0_172
- 1.8.0_181
- 1.8.0_222
- 1.8.0_275
recently upgraded to 1.8.0_302 and it seems to work like a charm.

Before these versions we used Oracles JDK jdk1.8.0_60, all in 32 bit arch version.


We had no problems either with OracleJDK or AdoptOpenJDK.
Also tried Zulu once and it also worked, but we didn't use it in production.

What are expected/known problems with AdoptOpenJDK or which alternative JDKs can we use (besides commercial not usable Oracle JDK)?
Phylanx
Expert
 
Posts: 201
Joined: Thu Aug 11, 2016 8:17 am

Re: Problems loading jcef.dll with AdoptOpenJDK

Postby magreenblatt » Wed Sep 01, 2021 9:17 am

The default OpenJDK install or Oracle should be fine on Ubuntu, only Oracle JDK is tested on other platforms. Other JDKs may have compatibility issues related to native window integration or jogl. Of course you can use other JDKs if you’re willing to resolve any issues.
magreenblatt
Site Admin
 
Posts: 12379
Joined: Fri May 29, 2009 6:57 pm

Re: Problems loading jcef.dll with AdoptOpenJDK

Postby Slartie » Thu Sep 02, 2021 11:59 am

I have had similar issues on Windows (and Linux as well) with different JDKs, be it AdoptOpenJDK or distribution-specific JDKs on Linux. It usually boils down to the process not being able to dynamically link jawt.dll (or libjawt.so on Linux) because it doesn't find that library. The library is stored in the JRE's lib subdirectory (assuming Java 8 JDK layout), but not in the JDK's, and if using the JDK's java.exe to run the application, that executable did not find the jawt.dll within the JRE/lib subdirectory. When running the application with the JRE's java.exe, it could load the lib and everything worked fine.

On Java 11 I have seen similar problems in a few cases, again only with some JDK builds (I'm not sure why these differences exist, but they seem to do things differently with regard to library search paths) and on some systems, it seemed to occur less often than with Java 8 (Debian's distro JDK package is the only one I remember that had the problem, but there might be others). There is no separate JRE subdirectory within the JDK anymore in Java 11, so the jawt lib resides in the JDK's lib directory now and should theoretically be found by a JDK Java process. However that sometimes appears to still be a problem, and in that case one must somehow help the process to find that library, either by putting it in LD_LIBRARY_PATH (on Linux) or by somehow preloading it before initializing JCEF.

I eventually ended up writing fallback code around JCEF init that catches linker errors, attempts to find the location of the library and load it manually using System.load(), then reattempts JCEF init afterwards.
Slartie
Techie
 
Posts: 11
Joined: Mon Sep 03, 2018 5:47 am


Return to JCEF Forum

Who is online

Users browsing this forum: No registered users and 4 guests