Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LWJGL library requires porting of JNI component #32

Open
HWilliams64 opened this issue Jun 9, 2018 · 13 comments
Open

LWJGL library requires porting of JNI component #32

HWilliams64 opened this issue Jun 9, 2018 · 13 comments

Comments

@HWilliams64
Copy link

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 #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)
@alexp-sssup
Copy link
Member

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.

@HWilliams64
Copy link
Author

HWilliams64 commented Jun 10, 2018 •
edited
Loading

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?

@alexp-sssup
Copy link
Member

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.

@alexp-sssup alexp-sssup changed the title Reference Error LWJGL library requires porting of JNI component Jun 11, 2018
@sourcerose
Copy link

sourcerose commented Jun 8, 2020 •
edited
Loading

@HWilliams64 Have you found a work-around yet? I would love to see LWJGL in CheerpJ! 😄

@sleirsgoevy
Copy link

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.

@sourcerose
Copy link

sourcerose commented Jun 17, 2020 via email

@alexp-sssup
Copy link
Member

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.

@sleirsgoevy
Copy link

sleirsgoevy commented Jun 18, 2020 •
edited
Loading

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.

@jsomeara
Copy link

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.

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.

@jsomeara
Copy link

image
Yep, exactly as I expected. It doesn't work with the regular CheerpJ. Interesting...I wonder if the JNI code is copyrighted...?

@gl91306
Copy link

gl91306 commented Nov 17, 2021

rip no lwjgl

@PurpleVoidEpic
Copy link

any updates on this?

@alexp-sssup
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@alexp-sssup @HWilliams64 @sleirsgoevy @sourcerose @gl91306 @jsomeara @PurpleVoidEpic