leaningtech
LWJGL library requires porting of JNI component
The system seems to get stuck on the screen that says “ Graphic system is initializing”
I am running it via a chrome web browser
My html file is specified below
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Hello World</title>
<script src="https://cjrtnc.leaningtech.com/latest/loader.js"></script>
</head>
<body>
</body>
<script>
cheerpjInit();
cheerpjCreateDisplay(800,600);
cheerpjRunJar("/app/test.jar");
</script>
</html>
In chrome I opened Inspector > Network Manager and was able to find this exception was being thrown
loader.js:390 Uncaught ReferenceError: _c4pbAOD$IvIXInEhrba1YelMKiZZcbdrJb$0y0getJNIVersionEVEI is not defined at N3org5lwjgl24DefaultSysImplementationX (test.jar.js:137292) at cjG (loader.js:2245) at N3org5lwjgl21J2SESysImplementationX (test.jar.js:137296) at cjG (loader.js:2245) at N3org5lwjgl22LinuxSysImplementationX (test.jar.js:137341) at cjG (loader.js:2245) at _c4pbAOD$IvIXYnlMKnTqebWeHiZZcbdrJb$mS3R3sNe5qO4ei (test.jar.js:137416) at _c4pbAaD$IvIXYnlMuCS3R3l (test.jar.js:137416) at N3org5lwjgl3SysX (test.jar.js:137414) at cjG (loader.js:2245)
I read over this thread https://github.com/leaningtech/cheerpj-meta/issues/30 and realized I didn’t add my main class. I subsequently added my main class to the html and produced what you see below
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Hello World</title>
<script src="https://cjrtnc.leaningtech.com/latest/loader.js"></script>
</head>
<body>
</body>
<script>
cheerpjInit();
cheerpjCreateDisplay(800,600);
cheerpjRunJar("/com/helloword/test/desktop/test”, "/app/test.jar");
</script>
</html>
And now its throwing this exception and it does not even get past the “CheerpJ runtime ready page”
loader.js:390 Uncaught ReferenceError: VQ is not defined at _Java_java_util_zip_ZipFile_open (icu.js:1) at cheerpjJNILongRetWrapper (loader.js:1764) at _i4pbNk9DgYZ$mYZhYcbUZdrJNe9xS44S3i (rt.jar.js:1673) at _i4pbN$8DgYZ$mYZhYcbNTNb9tSnIdorqeSOb9laRcSZaalGiceUa0fmNrhiS3l (rt.jar.js:1680) at _i4pbN$8DgYZ$mYZhYcbNTNb9tSnIdorqmSO3l (rt.jar.js:1680) at _i4pbNsajlVpce9HSqWz7zq_eBJ4Gteeepl69c (rt.jar.js:1514) at _i4pbNsajlVpce9HSqWz7jr_c79c (rt.jar.js:1514) at _c4FbMlG9cq$a_sCunE5rjWDiXYdruDVbXKjasd3cGK0xKdZiqKNe9pLe (rt.jar.js:1707) at _c4FbMlG9cq$a_sCunE5rjSDiXYdruTUWbHGIwZqPdWGjasJ3SOe9hS3c9BCo3cGKe (rt.jar.js:1707) at Object.func (loader.js:535)
Using cheerpjRunJar("/app/test.jar"); is actually correct. The real problem is that this JAR is trying to use the lwjgl library which has a significant binary (JNI) component. CheerpJ can only run pure Java applications or applications that have their JNI part ported to CheerpJ.
Ok, that makes sense as I received this Failure compiling org/lwjgl/opengl/ContextGLES.class when converting the Jar. I'll look into possibly writing my own or finding a work around.
I notice in the stack trace it says getJNIVersionEVEI is not defined where do I define the getJNIVersionEVEI? How do I port the JNI to CheerpJ?
native Java methods should be implemented directly in JS, this is documented here: https://github.com/leaningtech/cheerpj-meta/wiki/Implementing-Java-native-methods-in-JS
In particular the function ``getJNIVersionis part of theorg.lwjgl.DefaultSysImplementation``` class.
In am renaming this bug report to better represent the problem.
@HWilliams64 Have you found a work-around yet? I would love to see LWJGL in CheerpJ! 😄
I have something to add to the discussion. This demo loads a file named jni.js, and that file has a function named JNIGetEnv that returns a pointer onto the emulated heap. This suggests that CheerpJ probably has a working JNI implementation that is kept in private for some reason; it's hard to say anything specific without seeing the source.
Interesting.. Any word on when they will release the source code?
On Wed, Jun 17, 2020 at 3:18 PM sleirsgoevy [email protected] wrote:
I have something to add to the discussion. This demo https://cheerpjdemos.leaningtech.com/OpenAstexViewer.html loads a file named jni.js https://cjrtnc.leaningtech.com/2.1/jni.js, and that file has a function named JNIGetEnv that returns a pointer onto the emulated heap. This suggests that CheerpJ probably has a working JNI implementation that is kept in private for some reason; it's hard to say anything specific without seeing the source.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/leaningtech/cheerpj-meta/issues/32#issuecomment-645655452, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3V2DIACFI42FK6KRW666TRXE6LHANCNFSM4FEGCP3A .
CheerpJ includes an internal (partial) implementation of the JNI which itself is build with a modified version of our Cheerp compiler. We don't have plans to release this to the public due to lack of commercial interest for this feature.
It would also not be useful to run LWJGL. LWJGL uses the JNI to access the native graphic libraries, such as GLX on X11/Linux. A special web enabled implementation would still be needed.
CheerpJ makes it possible to directly implement Java native methods in JS (https://github.com/leaningtech/cheerpj-meta/wiki/Implementing-Java-native-methods-in-JS), that is the simplest way of implementing the JNI components of a library.
I once tried to port LWJGL to CheerpJ, and I don't think that reimplementing the whole JNI part of it in JavaScript is a good idea. The reason is that most of LWJGL's native code isn't actually platform-specific. IMHO the proper way to do it is either using JNI (either the official one, or a clean-room reimplementation), or reimplementing the whole library, not just native code, directly in JS, which would allow to emulate the high-level API instead of the low-level OS-specific calls.
EDIT: probably the main issue with implementing JNI is: NIO buffers and GetDirectBufferPointer (which LWJGL does use). Implementing that would require emscripten- or Cheerp-compiled code to run in the same pointer space NIO buffers and sun.misc.Unsafe operate on.
I have something to add to the discussion. This demo loads a file named jni.js, and that file has a function named
JNIGetEnvthat returns a pointer onto the emulated heap. This suggests that CheerpJ probably has a working JNI implementation that is kept in private for some reason; it's hard to say anything specific without seeing the source.
I also discovered: https://cjrtnc.leaningtech.com/2.1/jni.wasm I'm going to try downloading the original jar from the demo and then running it through cheerpjify.py and see if it achieves the same result as in the demo.
Yep, exactly as I expected. It doesn't work with the regular CheerpJ. Interesting...I wonder if the JNI code is copyrighted...?
any updates on this?
Not yet. With the new CJ3 architecture it will be easier to compile external JNI components, but as LWJGL depends not only on pure GL (which can be more-or-less directly mapped to WebGL) but also on X11, it will be a difficult project anyway.